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. 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.
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?
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 30 16:52:26 2004