Ah cool, did you tried the hgsubversion extension? Hadn't tried it by
myself
but it looks promising. Would't help in my particular problem but in
general
it would be cool.
Unfortunately that does not suffice the way it is currently implemented.
The issue is that in order to push changes to svn, it will always
require you to 'rebase' changes, meaning your history is messed up,
which also makes it impossible to share repositories and changes with
others, except when you only work with short-lived end-of-line
branches. You could imagine a group of people working on a feature,
and then at the end they put the changes into svn and discontinue the
branch.
Now there also is a solution. Currently the software is written in
such a way that there is a direct link between an svn changeset and a
hg changeset. Actually, a 1:1 connection. However, with distributed
rcs, the linear history disappears.
r means subversion revision, h is mercurial revision.
r1 -> r2 -> r3 -> r4 -> r5 -> m/r6
\-> h1 -> h2 -> h3 -----/
The feature that needs to be implemented is that when the h1-h3 +
merge changeset(s) are pushed, that that diff is committed to svn.
Then the hg-svn bridge needs to be taught that the whole sub-branch
corresponds to that revision in svn. Anyway, I will be looking at that
and possible solutions as my next project.
