On Thu, Oct 28, 2010 at 7:20 PM, Antonio vila <aavilagallego_at_gmail.com>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.
>
Or craft the log message in an external file and pass that file as the
commit message.
> Also, I think that the svn client could gather the info after inserting the
> comment to avoid this situation.
>
I don't agree with this. What about the situation where the last commit *is
not* supposed to be included in the tag?
The revision used for the copy should be the revision at the time the
command was initiated (which is exactly what happened in your situation).
Otherwise, what you asked the command to operate on, and what it actually
operated on, is not the same thing.
Cheers,
Daniel B.
Received on 2010-10-28 22:42:46 CEST