More SVN->HG questions

[Hans Meine]

On Thursday 09 July 2009 02:05:58 you wrote:
> 2009/7/8 Hans Meine <meine at informatik.uni-hamburg.de>:
> > 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".

I don't see a difference, or why it should be more trivial than the latter.

> Technically it's all the same to Mercurial, but we humans see the
> cases differently.  (Well, I do.)

Interestingly, our uses and views of mercurial seem to differ considerably. 
:-)

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

Ah, you're talking about branches in separate repositories.  Until now, I have 
practically always done full pulls/pushes, i.e. synchronized everything.  
Then, cherrypicking e.g. using transplant only *adds* things, so the result is 
still a superset of the older release.  (And I don't see a problem with 
keeping all releases in the same repo in my cases, but obviously your use 
differs here.)

Greetings,
  Hans