Python Goes Mercurial

[Patrick Mullen]

2009/4/3 Jeremiah Dodds <jeremiah.dodds at gmail.com>:
>
>
> On Thu, Apr 2, 2009 at 9:02 PM, andrew cooke <andrew at acooke.org> wrote:
>>
>> Echo wrote:
>> > 2009/4/2 Jeremiah Dodds <jeremiah.dodds at gmail.com>
>> >
>> >> 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.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>

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.