Mercurial, consistent merges, and submission convenience

[John Goerzen]

Hi,

I've been using darcs for awhile (and arch, svn, and cvs) before that.
I've been reading up on Mercurial lately and have a few questions.

If you're curious what I'm using darcs for, see
http://darcs.complete.org/ and http://software.complete.org/ -- I've got
several dozen projects under it.

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.

   If that is correct, then it seems that these commands are of
   very little use in collaboration between two people using Mercurial.
   Since if an imported patch has a different hash than it did in
   the repo from which is was exported, a merge conflict will surely
   arise with the exporter re-pulls from the other repo.

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

2) An equivolent to "darcs send".

   For those that don't know what darcs send does, it compares what you
   have in your local repo to the state of the repo you last pulled
   from.

   Then, it generates an email containing the native Darcs changesets
   that are present in your local repo that aren't in the remote.

   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.

   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

   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 )

   Because of the issue in #1, hg email seems to be inadequate for this.
   Plus, hg email also doesn't seem to be able to automatically figure
   out where to send the email to.

   The darcs mechanism is a lot simpler and less error-prone.  I want
   to make it absolutely as easy as possible for someone to pick up my
   code and send me patches, and darcs seems to win this one hands-down.

   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.

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.

   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?

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

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.

   Someone commented[2] on my original story and said that export/import
   is the way to go, but I am still dubious for the reasons stated
   above.

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.

Thanks for your insight.

-- John Goerzen

[1] http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html
[2] http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html#c42649