Python Goes Mercurial

[Patrick Mullen]

2009/4/2 Jeremiah Dodds <[email protected]>

The one thing that makes me want to use git more than any other dvcs is
that you don't have to create a new directory for branches. This may be
possible in other dvcs's , but git is the only one I've seen advertise
the
capability. [...]
That is the main reason why I switched to git at my work.
As for the git rebase, I don't ever plan on using that 'feature'. Even
though I would rather have had GvR pick git, I think he did a good job
deciding.

It looks like basically the same thing is accomplishable in hg, but is a bit
discouraged (I am not experienced with hg, and haven't read the docs
thoroughly, so I could be off base here). In most (d)vcs's , there is
normally a one-to-one relationship between project branches and directories
on your filesystem. In git, there is normally a many-to-on relationship
between project branches and directories on your filesystem - branching is
cheap and easy, and you can branch for every little fix or feature you want
to do, keeping one directory with multiple logical development paths with
basically no pain.

I don't think it's discouraged at all. There are several ways to
accomplish a similar workflow if you want a quick, short-lived branch.
The ones I know of, are named branches, bookmarks, and mercurial
queues. I have a hard time wrapping my head around what all of these
(and git branching) mean, since a quick branch is something I rarely
need in my personal development. The differences between each
approach is very difficult for me to see. But they all let you have
one set of files and work on disparate things at once to merge later.

Queues (which is a patch stack) seem useful but also dangerous, since
you can do a lot of switching back and forth without actually
commiting. Since you can apply any of the queues to your working
directory, they might work well for a short lived feature that you
potentially put into a real branch or into the main if the feature is
more complete and less experimental.

Named branches work off of a changeset I believe. At any time you can
rename the current branch, commit new stuff from that point in
history, and you have a new branch; using the name to keep track of
where you are. If you want to switch branches, you just update the
working copy to be the new branch you want to work from.

There are probably some advantages to how git handles things,
considering this is the main feature I hear cited at something git
does certifiably better, but I wouldn't know what that would be.

Oh, and merc recently got a rebase as well, for good or ill.

 

[Martin v. Löwis]

So what were these "strong antipathies" towards Git, exactly?

well if you find any, please do report back.

I don't like git because it is too difficult for me. In many cases,
git would refuse to do operations like updating or local committing,
producing error messages I was not able to understand (most of the
time including long sequences of hexdigits which I did not recognize,
or complaining about conflicts in long lists of files I knew I hadn't
touched at all). In some cases, I lost all my changes, and had to
do them all over again.

Regards,
Martin

 

[Lawrence D'Oliveiro]

I don't like git because it is too difficult for me. In many cases,
git would refuse to do operations like updating or local committing,
producing error messages I was not able to understand ...

Post an example of what you were trying to do, with the exact messages, and
we can walk you through it.

 

[Martin v. Löwis]

I don't like git because it is too difficult for me. In many cases,

Post an example of what you were trying to do, with the exact messages, and
we can walk you through it.

Unfortunately, these are many months ago, and I don't recall the exact
error messages. I wasn't really asking for help, merely pointing out
that I dislike git because it makes me ask for help (something I did
not have to do for CVS or subversion, except for very special cases).

Regards,
Martin

 

[Martin v. Löwis]

I don't like git because it is too difficult for me. In many cases,

Post an example of what you were trying to do, with the exact messages, and
we can walk you through it.

Unfortunately, these are many months ago, and I don't recall the exact
error messages. I wasn't really asking for help, merely pointing out
that I dislike git because it makes me ask for help (something I did
not have to do for CVS or subversion, except for very special cases).

Regards,
Martin

 

[Martin v. Löwis]

I don't like git because it is too difficult for me. In many cases,

Post an example of what you were trying to do, with the exact messages, and
we can walk you through it.

Unfortunately, these are many months ago, and I don't recall the exact
error messages. I wasn't really asking for help, merely pointing out
that I dislike git because it makes me ask for help (something I did
not have to do for CVS or subversion, except for very special cases).

Regards,
Martin

 

[skip]

Martin> I wasn't really asking for help, merely pointing out that I
Martin> dislike git because it makes me ask for help (something I did
Martin> not have to do for CVS or subversion, except for very special
Martin> cases).

In fact, Martin is generally the guy answering the CVS and Subversion
questions.

 

[Lawrence D'Oliveiro]

Unfortunately, these are many months ago, and I don't recall the exact
error messages. I wasn't really asking for help, merely pointing out
that I dislike git because it makes me ask for help (something I did
not have to do for CVS or subversion, except for very special cases).

Everybody needs help sometime. If you're accustomed to centralized version
control (CVS and SVN), it probably takes some time to get used to the way
distributed systems work. It's nothing to be ashamed of.

 

[Michele Simionato]

Everybody needs help sometime. If you're accustomed to centralized version
control (CVS and SVN), it probably takes some time to get used to the way
distributed systems work. It's nothing to be ashamed of.

If Martin - which is well above the average programmer -
says that he would need help with Git, I take this as
meaning that most people would get lost with Git.
Heck, I am getting lost even with SVN!

Michele Simionato

P.S. the thing I do not understand if why we are moving
away from Subversion. Will all the new features entered
in 1.5 and 1.6 Subversion is now not so bad as it used to
be and it has the advantage of being already there and
familiar to most people.

 

[Jeroen Ruigrok van der Werven]

P.S. the thing I do not understand if why we are moving
away from Subversion. Will all the new features entered
in 1.5 and 1.6 Subversion is now not so bad as it used to
be and it has the advantage of being already there and
familiar to most people.

I don't fully get the whole 'we MUST go DVCS!' meme going around the
Internet either.

There's situations where a centralised system like SVN works and there's
situations where a DVCS works better.

Unfortunately there's a whole group of rabid, zealous proponents of one
system or ther other out there that are quick to denounce any of your
rationale for going with one or the other if it is not their $FAVOURITE_ONE.

 

[Lawrence D'Oliveiro]

In message <262497db-d2fd-4217-978c-

If Martin - which is well above the average programmer -
says that he would need help with Git, I take this as
meaning that most people would get lost with Git.

I don't feel lost with Git. Does that make me an above-average programmer?

P.S. the thing I do not understand if why we are moving
away from Subversion.

Because it's still centralized. That means different developers cannot pursue
parallel branches on their own, those branches must be represented on the
server.

 

[Lawrence D'Oliveiro]

There's situations where a centralised system like SVN works and there's
situations where a DVCS works better.

Most of the people using Subversion seem to be corporates with a
centralized, top-down-controlled policy for development.

Conway's Law in effect, I guess.

Unfortunately there's a whole group of rabid, zealous proponents...

Tell you what, keep the ad-hominem bullshit out of this discussion, and I
agree to do the same. Deal?

 

[Michele Simionato]

Because it's still centralized. That means different developers cannot pursue
parallel branches on their own, those branches must be represented on the
server.

Yes, but Python managed to work this way for nearly two
decades and I am not sure the change is really required.
Notice that I did use a DVCS in the past (Darcs) and
in principle I like DVCS better, but in practice there
are too many of them nowadays, and I would wait for
a few years to see if the situation stabilizes before
changing the old route. But this point is moot, of course,
since the BDFL has already spoken. I take the core
developers are happy with the choice.

The relevance for me is that at work we use Subversion,
but now that Python uses mercurial I am sure there will
be coworkers wanting to switch to Mercurial and I would
like to understand what are the tradeoffs involved.

 

[Jeroen Ruigrok van der Werven]

Most of the people using Subversion seem to be corporates with a
centralized, top-down-controlled policy for development.

Not just corporations. An open source or other type of organisation might
just as well have requirements that mandate a different kind of policy.

Tell you what, keep the ad-hominem bullshit out of this discussion, and I
agree to do the same. Deal?

I guess I touched a nerve, so you must consider yourself one of those then.

Just for the record: I meant that there's always a group who actively push
one solution over all others without regard to what the current situation
demands. If you cannot step back and look at the whole without trying to
push your own things, there's nary a word other than rabid and zealous for
that type of behaviour.

 

[David Cournapeau]

P.S. the thing I do not understand if why we are moving
away from Subversion. Will all the new features entered
in 1.5 and 1.6 Subversion is now not so bad as it used to
be and it has the advantage of being already there and
familiar to most people.

I don't fully get the whole 'we MUST go DVCS!' meme going around the
Internet either.

I think it is often poorly 'marketed', and not well explained. But as
someone whose first source control system which made sense was a DVCS,
I can assure you that svn feels clumsy, slow, inadequate and extremely
primitive. Most people justification for svn is based on the fact they
are used to the workflow. Using DVCS to mimic the svn workflow is an
error IMHO. What would have happened if people tried to mimic the
visual sourcesafe workflow, with locks and co, with svn ? To me,
defending svn against DVCS is like defending the lock-per-file
approach of visual sourcesafe and the likes. Believe or not, there are
some people who think this lock-based workflow is better.

A simplistic analogy: svn it to CVS what C++ is to C, but try selling
C++ to python developers

David

 

[Jeroen Ruigrok van der Werven]

If you can look at the process that was followed in this decision and
see “push one solution over all others without regard to what the
current situation demands†you're not looking very hard.

I did not argue the decision for the Python project to use a DVCS at all,
which was evident from my initial email.

I merely stated that I cannot understand why there's a meme and/or group of
people on the 'net that vehemently declare that everything less than a DVCS
sucks.

 

[Lawrence D'Oliveiro]

In message <5f1038cd-b2c7-420d-

The relevance for me is that at work we use Subversion,
but now that Python uses mercurial I am sure there will
be coworkers wanting to switch to Mercurial and I would
like to understand what are the tradeoffs involved.

Eric Raymond has a good survey of what the important issues that they
address and the differences between them
<http://www.catb.org/~esr/writings/version-control/version-control.html>. I
would say that, basically, it's all about increasingly sophisticated ways of
handling merging.

 

[skip]

Lawrence> I don't feel lost with Git. Does that make me an above-average
Lawrence> programmer?

No, perhaps it just means git fits your brain better than it fits Martin's.
I have trouble understanding any of the DVCS tools, but I think it's mostly
because I'm overwhelmed by the seemingly infinite variety of workflows.

 

[Lawrence D'Oliveiro]

Python and Git should get along great.

<http://www.ulrikchristensen.dk/scripts/montypython/mrgit.html>