Mozilla: hg as a collaboration tool

[Mark Williamson]

> I didn't exactly say Mercurial is too complicated.  I said it's "more
> flexible and more complex" than CVS.  Does anyone disagree?

I don't fundamentally disagree but I'd like to add that whether it's 
conceptually simpler / more complex and whether it's harder / easier to use 
really depends on your usecase.

> Mercurial seems so simple.  Last week the question came up on IRC,
> "How do I get a patch containing just the changes I've made in my
> repo?"  The best answer came from dbaron:
>
>   <dbaron> Think of it like diffing the changes on a cvs branch.
>       You want to diff the base and the tip of the branch.
>   <dbaron> If you've merged the branch to a new base, you need to
>       diff against that.
>
> So the answer is: look at "hg log" and find your most recent merge
> from trunk.  Then "hg diff -r <trunk-parent-of-that-merge>".  If you
> type "hg diff -r <that-merge>", you get a plausible but incorrect
> patch.  If you just do "hg diff -r tip", you get a different incorrect
> patch.

I was asking a similar question recently for a different reason, so I've been 
thinking about this...

A slightly command would be to use "hg outgoing" to find what changes have 
been made in your local copy.  In the simple case where you've not been 
merging with upstream, you can just take the oldest changeset returned by 
that and diff it with tip.  That gets you a combined patch for all those 
changes and avoids you grubbing through hg log.  If you've merged with 
upstream during development, you're still in DVCS scary-land and need to 
think a but more :-) (been there, done that!)

> With CVS, the answer is "cvs diff".
>
> Now, it is possible to use hg just like you would use CVS.  Then you
> could just "hg diff".  But everyone will tell you not to do that.
> This guy is using hg as designed.  As a result, this basic operation
> is harder for him than it would be with CVS.

I wonder if a small change of workflow could make this easier for him?  If he 
regularly wants to get a "summary" diff if his changes against the mainline 
branch (i.e. a simple diff between his repo and mainline's) then I can see a 
couple of options:

a) just maintain a pristine mainline clone of mainline, diff against it as 
usual. (OK that's a bit gross, but it's what I've always done, even in the 
old days with bitkeeper)

b) maintain his changes in an hg named branch, then he (if my understanding is 
correct) should be able to do something like "hg diff -r mybranch -r 
default".

The b) case sounds like it might do what he wants (?).  Only problem I can 
forsee is that he probably wouldn't want to push this repository to mainline, 
or they'd end up with his named branch.  That's a bit unfortunate, but I 
don't know of a way of having a branch existing transiently within a single 
repository :-(  Ideally you'd want something like the "local tags" feature I 
guess...  There's the local branch extension but that seems a bit heavyweight 
for this usecase.

Maybe there's an extension that could make this easier.  It's a workflow that 
I quite often use.  For new projects, I've stared using the mq extension so 
that I'm maintaining patches directly rather than adding lots of unwanted 
goop to the changeset graph (your changes are then orthogonal).  But some 
kind of non-mq support for this would be simpler.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)