Bazaar Mercurial Plugin to access BitBucket

[Martin Geisler]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Barry Warsaw writes:
>  > On Oct 23, 2011, at 02:03 AM, Stephen J. Turnbull wrote:
>  > >Barry Warsaw writes:
>
>  > The other troublesome bit is that when I grab a clone, I get
>  > *everything* even for branches I might not care about.
>
> git init
> git pull /some/interesting/branch [more branches ...]
> git checkout /most/interesting/branch
>
> That's for git.  I don't know if the nomenclature above works on
> Mercurial named branches or bzr coloc branches, but some similar
> commands surely will.

The commands work for Mercurial too, but it's not normal to do it like
that. Users's are not supposed to know that 'hg clone' == 'hg init; hg
pull; hg checkout'. You can use 'hg clone --branch X --branch Y' instead
and I think the last branch mentioned is checked out.

>> [...] The fact that I can bring up all 5 versions of those in Emacs
>> from separate branch directories (in a shared repo), or just `head
>> oneiric/debian/changelog` without having to do any kind of branch
>> switching is *priceless*.

Making a new checkout to compare 5 versions will indeed be costly. I
would probably use 'hg cat' to retrieve the versions I need without
making a new checkout.

> Dunno about hg, but in git you can have all that at zero cost, maybe
> slight negative cost, vs. bzr.  Just use --local when cloning.  In hg
> it might cost some disk space if object storage can't be shared.  (hg
> does use hardlinks when cloning, but I don't know how quickly new
> storage is needed as the branches diverge.  At worst I suppose each
> file's history storage gets duplicated when that file diverges.)

That's exactly right: the history of each file is in a single "revision
log" in the .hg folder. They are hard-linked initially, but the links
are broken as soon as history diverges for a given file. You can relink
clones again if you like.

> I really don't see why Mercurial has to be a drag on your work in
> Python; it certainly is not due to the *fact* that it supports
> colocated branches.

Maybe that's an important point: Mercurial lets you co-locate your
(named or unnamed) branches into a single repository. But you can also
split such a repository again. Standing in a clone of CPython, I can do:

  $ hg clone --branch 3.2 . ../cpython-3.2

to get a clone with the 3.2 branch. The tip of 3.2 will be checked out
and 'hg update' will now stay on that branch. The 3.1 branch is present
in the clone since it is part of the history of 3.2, but 2.7 is absent.

> I have to think that you're just using inefficient/unreliable
> workflows for the tool in the context of Python. While you've done
> more than your share in improving Python's VCS system (even if your
> recommendation eventually came in second), and so I can't in justice
> say you should *work* on your workflow, I hope you'll take every
> opportunity to ask Mercurial experts to suggest improvements.t.

Definitely! The mercurial at selenic.com list is more suited for this
unless we can compare with an equivalent Bazaar workflow to make it
relevant for this list.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111025/f9612001/attachment-0001.pgp>