[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Pre and post bugfix tagging and mixed rev working copies

From: Mike Mason <mgm_at_thoughtworks.net>
Date: 2004-11-30 16:50:06 CET

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" .

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: 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" .

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?


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.