Random mercurial thoughts resulting from intense merging

Matt Mackall mpm at selenic.com
Sat Mar 24 01:00:59 UTC 2007


On Fri, Mar 23, 2007 at 05:51:30PM -0700, Chris Quenelle wrote:
> Stuart W. Marks wrote:
> >Your message contained some other scenarios that I couldn't quite 
> >follow. Did you want to discuss them further, or does the behavior make 
> >sense now? Also, I'd be interested in hearing about your use of hg to 
> >"maintain and resolve two long-term branches."
> 
> I probably got bit by the bug that has been discussed, and then 
> misunderstood
> it to mean that 'tags' were relative to either the working copy or the
> parent rev.  Apologies.
> 
> I really think there is a major philosophical headache in using
> a revision controlled file to store tags, but then treating them
> as "global" names.  The fact that you have implementation problems
> that requires establishing branch precedence is just a side-effect
> of a large design issue of what tags are really supposed to mean.

The deeper problem is that we're a distributed system. If there was
just one central repo, it would be trivial to keep revision-controlled
tags in a similar fashion.

But since we are a distributed system, we must deal with branches and
the resulting conflicts in some fashion. There is absolutely nothing
we can do to prevent two branches getting conflicting tag names.

I suspect the current changes will make this issue come up less often.

> I have a collection of about 10 or so snapshots over the last
> several years that constitute Sun's branch of libdwarf source,
> and SGI's branch. We only recently got the legal issues worked out
> to merge these, and I've been trying to use hg to bring them as close
> together as possible by removing white space differences and
> unnecessary deltas.  It turns out this was quite a stress test
> in a lot of areas.  It was an intense learning experience for me.
> Here's a random collection of items that come to mind.
> 
> -- I wish I could collapse revisions and remove them from the
>    current repository.  I had to do this several times by
>    creating the branches I wanted to keep, and pulling over into
>    a new repo and deleting the old repo.

This falls under the general heading of "history is immutable". As a
version control system, this is a good thing. You use it to protect
yourself from your own mistakes. If we let you try to clean up your
old mistakes, you are liable to make much more catastrophic and
irrecoverable mistakes.
 
> -- It seems like mq is a different mechanism to do the same
>    thing that mercurial already does natively.  Why
>    not mark some revisions as "temporary" and allow them to
>    be removed?  And never push/pull temporary revisions unless
>    you add the "force" flag.  Couldn't that replace mq?
>    Basically you need actions that duplicate a rev to make
>    it be derived from a different parent.  And you need
>    actions to remove a rev that doesn't have anything derived from it.
>    Not just the tip, but branches too.

Interesting notion.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial mailing list