On 10/28/10 4:20 AM, Antonio Ávila wrote:
Hello all, my name is Antonio Ávila and I'm an svn admin/user. I would like to
share what happens to me yesterday with a not so incoherent tag operation.
1. A team member commits changes in the trunk, at time t. (ending up in a
revision, let's say 2).
2. t+7 minutes later, we tag the trunk with the following command:
svn cp http://someIp/svn/trunk http://someIp/svn/tags/NewTag
After some time another team member discover that the changes that should be in
the NewTag aren't there... And the NewTag was generated from trunk, but revision
1 instead of 2.
So, what the hell happened?
Here it comes the answer.
Everything looked fine with svn info and svn log, the commands were right,
nobody made a mistake, apparently. And the commands looked fine on the temporal
line: first the commit, then the tag operation...
Looking into the access svn log in the server, what happened was that the tag
operation were "launched but not executed" 10 minutes before the commits in the
trunk and it was waiting for the user to write the comment. So the temp line
was:
1.- svn cp http://someIp/svn/trunk http://someIp/svn/tags/NewTag # waiting in
vim... (the rev info has been already taken trunk has rev 1)
2.- svn ci -m "some comment" # finalizes de operation trunk has now rev 2
3.- write comment in vim and :x # finalizes de operation, it doesn't regather
the revs infos, so rev1 is copied into the tag with the comment.
The "3" step, is registered with "3" time, instead of "1" time (what it's
logical...)
Well, this is an unusual situation, but it may happen to somebody in the future
and he may not realize what happened, so here is the experience. Don't leave
the svn operation waiting for the comment.
That's pretty much the nature of atomic operations - which you need for
concurrency. A commit is either completed or it doesn't appear at all. And it
obviously isn't completed until the comment is supplied.
Also, I think that the svn client could gather the info after inserting the
comment to avoid this situation.
Generally speaking the user (person, not program) should do an update after a
commit in case other people are also committing changes and to bring his own
working copy up to the HEAD revision. And perhaps more importantly, a revision
number should be specified in the copy to tag command instead of just hoping the
trunk is currently in the state you want. Even if you only have one person
making changes today, you should follow a procedure that will still work when
you have concurrent changes and the trunk may have moved past the state you
wanted to tag by the time you issue the command.
--
Les Mikesell
lesmikes...@gmail.com
