Eric Wong wrote:
Joakim/Steven:
Any further testing and test cases would be appreciated. Be very
careful with real-world repositories, and run dcommit with the
'-n' flag before actually committing to verify the diffs are sane.
I poked at this some tonight with an eye toward the use case of using
git to merge svn branches. I ran into one inconvenience and one bug.
I'll try playing with the "use lots of git branches to develop on one
svn branch" use case some too, but for now, here are the notes I took,
along with the commands if anyone wants to reproduce what I did.
Hopefully this won't be too annoying to read. The bug is near the bottom.
svn repo with a trunk and a branch, each with changes (no conflicts at
first, keep it simple to start)
$ svnadmin create svnrepo
$ svn co file://`pwd`/svnrepo svnclient
$ cd svnclient
$ mkdir trunk tags branches
$ echo test file number 1 > trunk/testfile1
$ echo test file number 2 > trunk/testfile2
$ svn add *
$ svn commit -m "initial commit"
$ echo trunk change 1 >> trunk/testfile1
$ svn commit -m "trunk change 1"
$ echo trunk change 2 >> trunk/testfile2
$ svn commit -m "trunk change 2"
$ svn cp trunk branches/mybranch
$ svn commit -m "make a branch"
$ echo trunk change 3 >> trunk/testfile1
$ svn commit -m "post-branch change in trunk"
$ echo branch change 1 >> branches/mybranch/testfile2
$ svn commit -m "change in branch"
git-svn clone of this dinky repo
$ cd ..
$ git-svn clone --trunk=trunk --branches=branches --tags=tags
file://`pwd`/svnrepo gitclone
$ cd gitclone
Try to merge trunk change into branch using git
$ git reset --hard mybranch
$ git merge trunk
Conflicts! what's going on?
$ gitk --all
Aha, looks like git-svn guessed wrong about where I made the branch; it
thinks the branch comes from the initial rev. Easy enough to hack
around, but might be nice to be able to do this using git-svn's history
rewriting rather than a grafts file.
$ echo `git-svn find-rev r4` `git-svn find-rev r3 trunk` > .git/info/grafts
$ git reset --hard mybranch
$ git merge trunk
No conflicts now. Let's see what git-svn thinks it should do
$ git-svn dcommit -n
Looks like the right diff
$ git-svn dcommit
Refresh gitk display. Looks good, the new revision is a merge with the
right parents. Let's check it out in svn land
$ cd ../svnclient
$ svn up
$ cat branches/mybranch/testfile1
Yep, the trunk change is there, nice! Now for a couple more revs with a
conflict.
$ echo post-merge trunk change >> trunk/testfile1
$ svn commit -m "trunk change after merge"
$ echo post-merge conflicting change >> trunk/testfile2
$ svn commit -m "trunk change with conflict"
$ cd ../gitclone
$ git-svn fetch
$ git merge -m "change with conflict" trunk
Conflict, as expected
$ vi testfile2
$ git add testfile2
$ git commit
$ git-svn dcommit
Transaction is out of date: Out of date: '/trunk/testfile1' in
transaction '9-1' at /Users/koreth/git/git-svn line 398
Hmm, this merge was in mybranch, not in trunk
$ git log --first-parent
Yes, the most recent commit with a git-svn-id line has a mybranch URL.
So why is it complaining about a trunk file being out of date?
My experimentation pretty much ended there (I tried a few things to
clear the error up, but none of them helped.)
This machine is an OS X laptop. Subversion is 1.4.3 (r23084) from
MacPorts. I used the git-svn from the "pu" branch since it had this
patch and all the recent fixes.
Let me know if you need more details. Hope this is helpful.
-Steve
-
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
