Mercurial, consistent merges, and submission convenience

[Thomas Arendsen Hein]

* John Goerzen <jgoerzen at complete.org> [20070224 18:18]:
> 1) Accuracy of hg export/import.
> 
>    From reading the docs, it appears that an "hg export" from one
>    repo, then an "hg import" in another, is *not* the same as 
>    pushing a changeset from one repo to the other, right?  That is,
>    copies, renames, permission changes, patch hash, patch parents,
>    etc. will not be preserved.

Usually not, but you can make it this way:

- The patch header contains the parent node, but you have to update
  to this node manually.

- "hg export --git" preserves copy/move/executable and even binariy
  content by using the extended git patch format.

>    Why, then, does hg email use hg export instead of hg bundle?

Because you can't expect the whole world to use Mercurial. Plain
(non-git) patches are accepted by almost any project.

Maybe a config/cmdline option to send bundles via email would be
what you want.

> 2) An equivolent to "darcs send".
> 
>    Finally, if the remote repo has specified an email address for the
>    maintainer, darcs can automatically look up the email address to send
>    the bundle to, and sent it away.

Mercurial doesn't have this "maintainer email address" field.

>    Thus, it's incredibly easy for a new person to download source,
>    commit, and send me a set of darcs changesets:
> 
>    darcs get http://wherever.org/blahblah
>    hack and darcs record
>    darcs send

Hmm, might be really nice. Shouldn't be very hard to do as an
extension where a .hgsomething file in the repo contains the
maintainer address and maybe if this maintainer prefers bundles or
patches.

But I don't know how suitable this would be for general use, imagine
people cloning the main hg repo, doing some work on it and publish
it on their web server. Now I clone this secondary repo (which still
contains .hgsomething pointing to mercurial-devel list), hack and
commit, then 'hg darcssend' would send e.g. a bundle to the list
which doesn't apply to main hg!

Remember that during hg clone nothing except the repository content
is transfered!

A solution for this might be if .hgsomething contains not only the
email address and bundle/patch format preference, but the canonical
repository URL, too, so this information is only used when sending
bundles relative to this repo. But this needs some special handling
(following of the clone chain?) for local clones, too, as I usually
keep a clean clone of every upstream repo and use this one for
outgoing/bundle/email (and of course for creating a number of
additional working clones because this gives me the benefit of
hardlink clones).

>    In Mercurial, the process looks more like:
> 
>    hg clone http://wherever.org/blahblah
>    hack and hg commit
>    hg bundle /tmp/foo http://wherever.org/blahblah
>    ( look up the email address for the maintainer at wherever.org )
>    ( compose an email to that maintainer, attaching /tmp/foo to it )

Of course these are some additional steps. The benefit is that there
is less magic behind them. Behaving non-magical is one of the main
benefits of Mercurial's core (and my main problem with darcs).

But I have no problem with magic added by extensions, as users have
to enable this magic deliberately (unless some package maintainers
decide otherwise).

>    Like Mercurial, darcs users often push/pull from a central server.
>    But darcs send can also GPG-sign a changeset bundle.  So some people
>    set up an email processor that receives GPG-signed bundles,
>    verifies that the signature comes from an authorized person, and then
>    applies them to the darcs repo.  That way, you can effectively
>    do an "offline push".  AND, these same email processors often dump
>    unsigned patches into a mailbox or mailing list for human review.
>    Very slick, IMHO.
> 
>    It seems that Mercurial could do all this without much effort.

Yes, sounds really nice for some setups and should be easy to
implement. The darcs implementation for this could be ported.

> 3. I am confused about mq.  I read through the "Distributed Revision
>    Control with Mercurial" PDF (an excellent resource, BTW).  It stated
>    two things that seem to conflict:
> 
>    1) Mercurial changes can never be removed once they are made.
>       (With the limited exception that the very last one can be removed
>       with hg rollback)
> 
>    2) hg qpop removes changesets.
> 
>    This seems boggling.

qpop is part if mq, which is an extension which violates the
append-only paradigm of Mercurial.

>    Also, how does one share repos that use mq publically, if all this
>    history altering is going on?  It seems a recipe for disaster with
>    pushing/pulling.  Not only that, but if .hg/patches is a separate
>    repo, I guess I would have to push two different things in order
>    to push my local tree of hacks to the remote?

You should not allow direct access to your working repo with mq
patches applied, but you can push it to a temporary location with a
warning sign: "Be prepared that hashes change"

If people pull from this repo after the patch queue changed, their
repo gets an extra head which can be stripped using the 'strip'
command of the mq extension.

The second alternative is of course to publish your patch queue
(.hg/patches) directly.

>    How also does all of this differ from the TransplantExtension,
>    which seems to do the same thing?

With mq you have the qrefresh command to change patches until you
and/or upstream like them. With transplant you can cherrypick or
rebase existing patches but not modify patches.

> 4. Back last August, I looked at a number of distributed VCSs and wrote
>    about them[1].  One main thing that bugged me about Mercurial was
>    that it doesn't have the darcs-like support for cherrypicking
>    changesets.  That is, if I pull changeset 10 from a remote repo,
>    I have to also pull changeset 1-9 from it (or already have them 
>    in mine).  What if I want only changeset 10?
> 
>    I could manually use hg export/import, but then I'd get a conflict
>    when it comes time to merge changeset 10 later.  (Plus, changeset
>    10 would be listed as a parent of the merge, not right away during
>    the import.)  Or, I could pull everything and manually remove
>    the changesets I don't want -- but then a later pull from the repo
>    would never pull them in again.

You could backout your cherrypicked 10 and then pull+merge as usual.

Or use the TransplantExtension which is designed to do cherry
picking. It adds a mark to transplanted changesets (visible with
'hg log --debug' in the transplant_source extra field).

If you can make the repo you picked from pull from your repo, the
conflict will be much easier to handle, as the source repo can
simply merge with your changes reverted before committing (if you
only have cherry picked changes)

> I'm intrigued by a number of Mercurial features (such as its copy
> support, plus mq) and would like to try it out, but I don't think I'll
> find it useable unless I can figure a nice way around some of these
> things.

Darcs and Mercurial are very different concepts, both have
advantages.

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrück - Registereintrag: Amtsgericht Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner