More SVN->HG questions

[Robert Bauck Hamar]

*Georg:
>If you want to transfer a single changeset from 'default' to 'v1.3', you
>could use hg export / hg import. If you already hg pulled all of 'default'
>into 'v1.3', you could also use hg transplant (transplant only works between
>branches within one repository I believe).

This is wrong, fortunately:

hg transplant -s ../other-repo [...]

will get changesets (revisions) from repo in ../other-repo

>However keep in mind that you are waving Mercurials change tracking this
>way.

Somewhat, at least. Transplant records the original changeset id in the 
extra field. But I can't see it's used anywhere. (Is there any plans on 
doing this?)

>You have to track what has been merged where, manually, on paper or
>elsewhere.  SVN up to 1.4.x did not track merges at all so maybe you are
>used to this kind of homework already.  However most other VCSs, and also
>SVN 1.5+ do offer some way of automatic tracking what has been merged where.

As well as svnmerge.py, which is very similar to svn 1.5. In my 
experience, Mercurial behaves better, though.

>Mercurial tracks 'complete-to-rev' merges, i.e. if you were to merge r12345
>from branch a to b, then it would effectively merge all changes in all files
>up to that rev, and remember so.  Subsequently if you were to merge r12349,
>it would remember that only the 4 revs in between need to be merged, and
>again this would be remembered for the future.
>
>SVN 1.5+ tracks individual changesets merged, I believe, i.e. think of a
>bitmap where each bit records one changeset. There is some flexibility for
>marking ranges of changesets as "don't merge",

Yes. But the need for this can in Mercurial be avoided by using 
different branches/clones for different features, and, in some cases, hg 
backout.

>ask "which changesets are still unmerged", and merge specific 
>changesets (cherry-pick). However from what I heard there are still 
>significant pitfalls, you should merge in one direction (say a-->b) 
>only EVER, you should forget the branch after you "reintegrate". (I'm 
>not using SVN myself so I might be wrong.)

You are correct. I would believe SVN could be much better if it tracked 
changesets' parents, thoug.

>The preferable approach is usually to fix a bug on the 'lowest' bugfix
>branch and then merge forward 'complete-to-rev', as others have already
>pointed out.

With Mercurial, one can easily go back and find old changes quickly. 
It's often a good idea to go back to the oldest changeset with the bug, 
and then commit the fix there, before merging this with the affected 
heads.

You can use hg annotate (as in svn) and hg bisect to find the changeset 
introducing the bug quickly.

>There might be a problem in that the converted repo does not have any memory
>of prior merges, yet quite probably there was a lot already merged between
>'default' and 'v1.3' before you converted. So your initial merge history
>could be blank, and your first merge might raise lots of artificial
>conflicts.

You could (and should, probably) insert these yourself. Find the proper 
changeset in default, pull it in, and merge (use internal:local as the 
merge tool).


I cut away the text below. It's there in earlier posts if you need it.

-- 
Robert Bauck Hamar
USIT/SAPP/GT - Cerebrum
http://www.uio.no/sok?person=hamar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090708/44cdabd7/attachment.pgp