5

In my company we have a subversion server and everyone is using subversion on their machines. However I'd like to use git, committing changes locally and then "push" them when I'm ready.

However, I can't understand what happens in the following situation. Let's say that I made 3 git commits locally and now I'm ready to "push" everything on the subversion server. If I understand correctly, git svn dcommit should basically make 3 commits sequentially on the server, right? But what happens if in the meantime (let's say between the second and the third commit) another colleague of mine issues a commit? The scenarios I can think of are:

1) git kind of "locks" (is that even possible?) the subversion server during commits so that my commits are doing atomically and my colleague's one is done after mine

2) The commit history on the server becomes mine1-mine2-other-mine3 (even if 'other' should fail since my colleague doesn't have an updated working copy at that point).

I think it's #2, but perhaps the committing speed is so high that this seldom becomes an issue. So which one is, #1 or #2?

Emiliano
  • 22,232
  • 11
  • 45
  • 59

2 Answers2

5

No locks are not supported in Git, it's not a Git way (Git way is branching and merginig). With git-svn you'll get mine1-mine2-other-mine3 history. If you need atomicity, have a look at SubGit project (it is installed into the SVN server and creates a pure Git interface for the SVN repository).

There was a similar question recently that might be interesting for you.

Community
  • 1
  • 1
Dmitry Pavlenko
  • 8,530
  • 3
  • 30
  • 38
  • +1 Anyway I think the problem is that the SVN server doesn't support locks. Even if it was the git way, there is just nothing to lock, I fear. – Emiliano Jul 03 '12 at 17:13
  • You only get mine1-mine2-other-mine3 history if you are lucky. If you are not then your dcommit stops and you have to follow the procedure listed above to get the commits which weren't committed back. – Rutix Jul 03 '12 at 17:15
0

If you are lucky then number 2 but most of the time you aren't that lucky. In my experience when I dcommit a lot of commits and someone else commits while doing that usually 2 things happen:

  1. It stops with dcommitting your other changes.
  2. You lose the commits not-yet dcommitted.

Number 2 is really really annoying. The main problem is that you need to be totally up-to date to use git svn dcommit. This is because git-svn doesn't let the server merge revisions on the fly. (Because it would require both committers to have a working tree with both changes).

The only way to solve this are the following steps which I found here

  1. Open .git/logs/HEAD
  2. Look for your most recent commit (note that these commits are sorted by “unix time”, although you can also find the latest one by reading the shortlog there
  3. Confirm that the commit you found is the right one: git show
  4. git reset --hard hash from log
  5. git svn rebase
  6. git svn dcommit

Following this procedure allows you to take off from where it failed. I hope they fix this soon but they said this isn't priority for them yet.

Ofcourse if you commmit small groups and have a fast connection to the server it shouldn't happen that often. (I only got it 2-3 times when actively working and committing every day for 6 months).

Rutix
  • 861
  • 1
  • 10
  • 22
  • Another option is to squash before pushing so that I have only one commit per time although it may be quite large – Emiliano Jul 03 '12 at 17:02
  • Only committing one commit should give you less problems. Although this ofcourse kinda goes against the principle of the whole commits :). I added some information about what the main problem is in this case. – Rutix Jul 03 '12 at 17:10