On 9/2/11 11:07 AM, Bryan Jacobs wrote:
For this particular case, it works well: svn:mergeinfo is populated in such a way that the local merge history is recreated when another git-svn user pulls down the repository. This patch thus allows to git users to exchange branching and merging development through a central SVN server without loss of fidelity and without explicitly manipulating the mergeinfo property by hand.
Whee! That's what I was intending when I wrote the original change. I
might have written it myself back in 2008 or whenever it was, but I
found I didn't actually have any SVN projects I was sending commits to,
let alone merges. git-svn is a project with a continually atrophying
userbase :-). Thanks for picking it up.
If the user has made commits to two local branches, merges them with --no-ff, and attempts to dcommit the result, the tool will error out with a message stating that all parents must reside in the SVN repository before their merge can be committed.
I was unable to discover a way to clean way to restore the repository state in the case where this happens before reaching the HEAD commit. For example:
r1 --- B --- C -- F
\ /
r2 --- E ------
If r1 and r2 already reside in SVN, git-svn will dcommit B and C, then error when it tries to dcommit F (since the SVN revision number for E has not yet been set; the user should dcommit E before dcommitting F). The repository SHOULD be set to the following state after this happens:
r1 -- r3 -- r4 -- F
\ /
r2 --- E ------
... but git-svn seems to put all the changes from all objects that it will be dcommitting into the working copy, which means that cherry-picking F atop the state the WC is in fails (due to conflicts with "untracked" objects already added). So in this patch if you try the above, you actually end up in this state:
r1 --- r3 -- r4
\
r2 --- E
F is lost and cannot be cherry-picked back onto the WC, as any files created in E are already present but untracked locally.
Are r1 and r2 supposed to be on the same SVN branch?
Overall, I could believe that. Perhaps it is simpler to detect those
situations in advance and insist the user dcommits them independently,
although it appears to me that it would apply to any dcommit which
failed for any reason part way through. So perhaps there is a wider
justification for fixing that.
Sam
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html