Mike Mason <mgm@thoughtworks.net> writes:
> I'm coming at this from a CVS perspective so my strategy might just be
> all wrong, but bear with me for a moment...
>
> I'm fixing a bug. It's a fairly complicated bug so I'm not 100% sure I
> can fix it in one commit. I check out my release branch, and in order
> to make applying the bugfix elsewhere easier I tag the current state
> of the code, before I fix the bug:
>
> release-1.0> svn copy -m "start fixing bug"
> . svn://myserver/myproj/tags/PRE-mybugfix
>
> Now I try fixing the bug. I make a change, think I'm done, then check
> in. Oops, didn't quite fix all the edge cases. Fix some more, check
> in. Now I'm really sure I've fixed the bug, and I try
>
> release-1.0> svn copy -m "finish fixing bug"
> . svn://myserver/myproj/tags/POST-mybugfix
> svn: Commit failed (details follow):
> svn: Out of date: '/myproj/tags/POST-mybugfix/common/Flibble.java' in
> transaction '2y'
>
> Subversion is complaining that Flibble.java is out of date (and in
> fact that's one of the files I changed during my bugfix). If I do an
> update, *then* commit everything is fine:
>
> release-1.0> svn update
> At revision 63.
> release-1.0> svn copy -m "Finish bug fix"
> . svn://myserver/myproj/tags/POST-mybugfix
>
> Committed revision 64.
>
> Now since the update isn't giving me any new files, Flibble isn't
> really out of date and this is Subversion complaining about mixed
> revision working copies.
I think this is a bug in Subversion, really. Why is it unwilling to
tag (copy) a mixed-revision working copy to the repository? We
explicitly designed that feature into Subversion, it's not like it's a
surprise. In fact, it's supposed to even be able to copy locally
modified files, when you do a wc-to-repos copy.
Can you make a short reproduction script that demonstrates the problem?
> My problem is that if I do the update before
> the commit, I might get someone else's changes and tag those as being
> part of my bugfix.
Understood.
> Is there a workaround for this? Is pre-and post-bugfix tagging in
> Subversion a waste of time and I should be tracking the revision
> numbers used in a commit instead? Did I miss something obvious, and am
> I being dumb?
Only you can decide whether the bookkeeping is a waste of time.
Personally, I did wonder why you bothered to make the first tag at all
-- and why you did it from your client side! After all, that was a
fresh checkout. So you might as well make the tag by doing a
URL-to-URL copy. Same result, *much* faster.
But wait, there's more: then you did multiple checkins on your tag.
So it wasn't really a tag. You should have called it a branch
instead. Then the bugfix would simply be "all the changes committed
on the branch, that is, the total diff on the branch". You could use
'svn merge' to put those changes onto the release branch, or any other
place, when ready.
That IMHO would be the more Subversion-y way to do things.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 1 17:14:43 2004