More SVN->HG questions

[Greg Ward]

2009/7/8 Hans Meine <meine at informatik.uni-hamburg.de>:
> On Tuesday 07 July 2009 21:28:49 Greg Ward wrote:
>> In your case, it's "pull" rather than "merge", because you're using
>> separate repos rather than named branches within one repo.  But at a
>> conceptual level, it's all the same.
>
> Wouldn't you still need to merge after pull?

Err, yes, good point.  But that's the trivial "merge to integrate what
I've just pulled", not "merge work on branch n to branch n+1".
Technically it's all the same to Mercurial, but we humans see the
cases differently.  (Well, I do.)

>> One way to think about is this: the graph of changesets in the repo
>> for release n+1 should be a superset of the graph for release n.  Of
>> course that's a pie-in-the-sky ideal that won't happen in real life,
>> but it never hurts to strive for an ideal.
>
> Why won't it happen in real life?  AFAICS, this might only become wrong when
> you change history (i.e. strip/mq/histedit/...), which you would typically
> only do with non-shared changesets.

The ideal "branch n is a subset of branch n+1" scenario breaks down
when you need to cherrypick a fix back to an older branch, or when you
deliberately skip some branch while merging forward to the trunk.
Open source projects can get away without such annoyances, but these
sorts of things that happen when there are real paying customers on
the other end of the line.  (At least at my job they do.)

Greg