git-svn can lose changes silently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



git-svn is happy to overwrite changes in the svn repository with no warnings. Didn't seem to be known behavior when I mentioned it in #git, so here's an example, starting completely from scratch to make it easier to reproduce. I'm using git-svn 1.4.3 and svn 1.2.3 on OS X.

First I create a new svn repository and stick a test file there:

% mkdir /tmp/svntest
% cd /tmp/svntest
% svnadmin create svn-repo
% svn co file:///tmp/svntest/svn-repo /tmp/svntest/svn-client
Checked out revision 0.
% cd /tmp/svntest/svn-client
% mkdir -p project/trunk
% echo "initial contents" > project/trunk/testfile
% svn add project/trunk/testfile
svn: 'project/trunk' is not a working copy
% svn add project
A         project
A         project/trunk
A         project/trunk/testfile
% svn commit -m "initial commit"
Adding         project
Adding         project/trunk
Adding         project/trunk/testfile
Transmitting file data .
Committed revision 1.

Now I clone that svn repository using git-svn and pull in the contents of the svn repo:

% cd /tmp/svntest
% git-svn init file:///tmp/svntest/svn-repo/project/trunk git-repo % cd git-repo
% git-svn fetch
       A       project/trunk/testfile
Committing initial tree 9ca0a5a8cb5ee41744aaf17f859e945f2ebaa7d4
r1 = 63c70a5e17ffb095a31e96b1a56612f1f8423202

Now I create a development branch and commit a change to the test file:

% git-checkout -b devel
% echo "a second line from the git side" >> testfile
% git-commit -a -m "git-side commit"

Now I go make a change on the svn side and commit it.

% cd /tmp/svntest/svn-client/project/trunk
% echo "a second line from the svn side" >> testfile
% svn commit -m "a second svn commit"
Sending        trunk/testfile
Transmitting file data .
Committed revision 2.

At this point the svn repository has the testfile with two lines: "initial contents" and "a second line from the svn side". Now, back on the git side, I commit my git-side change to svn (here's where the bug happens):

% cd /tmp/svntest/git-repo
% git-svn dcommit diff-tree 679c0db253781216b9b72b51f2dfffec5711f1a3~1 679c0db253781216b9b72b51f2dfffec5711f1a3
       M       testfile
Committed 3
       M       project/trunk/testfile
r2 = 7d7923588ffb41eb756959d71623581df9318603
       M       project/trunk/testfile
r3 = 25a5fefe01389260274bb2617bc36a2cce18f15d
No changes between current HEAD and refs/remotes/git-svn
Hard resetting to the latest refs/remotes/git-svn

Finally, I go back to the svn side and update from the repo:

% cd /tmp/svntest/svn-client
% svn up
U    project/trunk/testfile
Updated to revision 3.
% cat project/trunk/testfile
initial contents
a second line from the git side

The change I checked in from the svn side has vanished without a trace, no warning messages or anything.

It is probably not a feature that you can lose changes without knowing about it! Even if I'd run git-svn fetch before that commit, it still wouldn't help if the svn version of the file changed between the time I ran fetch and the time I ran dcommit, totally possible with a busy svn repository.

Opinions? Suggestions on fixing it? Do other people agree this is a bug?

-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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]