Random mercurial thoughts resulting from intense merging

Chris Quenelle Chris.Quenelle at Sun.COM
Fri Mar 23 19:51:30 CDT 2007


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.
But that's a really fuzzy subject, and I have something more concrete
to discuss.  :-)

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.

-- 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.

-- I really polluted my revision history when I started trying
    to assign tags like newsgi, oldsgi, newsun, oldsun.
    I should have been using local tags, but there was no way
    to remove the revs that added the tags, so "hg log" turned
    into a mess.

-- I've been using kdiff3 on a windows box for merging, and I like
    it a lot.  I like using it to merge entire directories.
    But hg is set up to merge one file at a time.  My merge process
    sometimes involved some heavy use of "hg diff -r X -r Y"
    to figure out what to do.  I didn't like it that merging
    put my whole repo into "merge mode".  Specifically, the
    "parent rev" becomes +123+456 with two parents. I ended up
    creating a specific branch that was the "merge result" that I wanted,
    and then merging (with HGMERGE=/dev/null), and then copying
    that branch into the working copy, and then committing.

-- Direct support for a directory-based merge tool might be nice.
    I did this by creating temporary repos, but I'm not sure that's
    a good idea with huge repos.

-- Bundling some guis with hg would be nice.  I've dumped XML output
    compatible with the yEd graph tool before.  That seems like a cheap
    and easy way to visualize trees and graphs.  I know there are
    some out there, but I haven't dug them up yet.

-- I like kdiff3 a lot.  It has a menu item that lets you select one
    favored input file for all white-space conflicts.  I wanted to
    use that a couple times, but it didn't seem to work.  But I really
    like its directory merge mode. It also has the ability to split conflicts into
    two parts for those times when the conflict detection algorithm
    doesn't line things up right. And I downloaded a windows binary that
    just worked.  Cross platform is very nice.


> 
> s'marks
> 
>>
>> A similar surprise came up with my use of "hg log" a few weeks ago.
>> (See below the "------")  It resulted in me deciding not to use
>> non-local tags until someone explained how to use them in a
>> non-confusing way.
>>
>> My situation might be special because I'm using hg to maintain and 
>> resolve
>> two long-term branches.  So I have lots of special 'hg diff' aliases
>> and I often have to use 'update' to set myself back to specific versions
>> over and over again.  I might be using hg more "intensely" in this
>> respect than what is normally done. (Or maybe not)
>>
>> So what follows is my story...
>>
>> ----------
>>
>> I was surprised a few weeks ago by some strange tag behavior.
>>
>> (What's the official term for "currently set/assigned CS" ?
>> In other words a name for "current output of 'hg id'"
>> I'll call it "current CS" for now)
>>
>> I was adding some various tags to changesets and realized that
>> not all my tags were showing up in "hg log" output.
>> It turned out my current working CS (via update -C NN)
>> was set to a CS from before I added the tags.  So later tags
>> didn't show up in the "hg log" output.  But the CS's that
>> were the target of the tags *did* show up (obviously).
>> It doesn't make sense for a CS defined after my current CS
>> to show up in the output, but a tag defined after my current CS
>> to be hidden.
>>
>> Of course, if I think about how it works, then it makes sense
>> that the .hgtags file being used is the version from the current CS.
>> But it could easily be implemented a different way.
>>
>> Anyway, if you want to claim that "hg log" output is relative
>> to the current CS, that's okay, but then the log output should
>> only show CS's that contribute to the current state.
>> (Other CS's could be hidden with a warning or something)
>> Then you could have "hg log -a" show everything or something like that.
>>
>> Otherwise, if "hg log" is supposed to show global output,
>> then make it independent of what the current CS is, and
>> use all the various .hgtags versions to attribute tags
>> to CS's.  In this case you bite off the problem of establishing a
>> "global tag context".  That's problem that's been discussed in
>> this thread recently.  But the problem is there is no true
>> "global context" because tags are applied or move *locally*
>> within a changeset.
>>
>> --chris
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial


More information about the Mercurial mailing list