You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mike Mason <mg...@thoughtworks.net> on 2004/11/30 15:50:06 UTC
Pre and post bugfix tagging and mixed rev working copies
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
Re: Pre and post bugfix tagging and mixed rev working copies
Posted by Michael Mason <mg...@eskimoman.net>.
On Wed, 1 Dec 2004, Michael Mason wrote:
> On Wed, 1 Dec 2004 kfogel@collab.net wrote:
>
> > 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?
>
> I'll do that, will attach in another mail.
Humph. I can't seem to get it to reproduce with 1.1.1, so maybe I was
using 1.0.x when I had the original problem, or I'm not reproducing it
right. I'll have another go later tonight when I have more time.
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre and post bugfix tagging and mixed rev working copies
Posted by kf...@collab.net.
Michael Mason <mg...@eskimoman.net> writes:
> # start working on a bug fix
> svn copy -m "start bugfix branch" \
> svn://myserver/myproj/branches/RB-1.0 \
> svn://myserver/myproj/bugfixes/BUG-123
> svn copy -m "tag start of fix" \
> svn://myserver/myproj/bugfixes/BUG-123 \
> svn://myserver/myproj/bugfixes/BUG-123-START
> # check out code to work on bug
> svn checkout svn://myserver/myproj/bugfixes/BUG-123 bug-123
> # fix, doing multiple commits
> # we're done fixing, now mark the end of the bugfix
> svn copy -m "tag end of fix" \
> svn://myserver/myproj/bugfixes/BUG-123 \
> svn://olio/sesame/bugfixes/BUG-123-FINISH
> # Merge the bugfix into release 1.0's branch
Why are you tagging the start and end of the fix? That set of changes
is already isolated on the bugfix branch. You can just run
svn log svn://myserver/myproj/bugfixes/BUG-123
to see the entire history of the fix, from bugfix branch creation to
final commit on the bugfix branch.
> cd rb-1.0
> svn update
> svn merge \
> svn://olio/sesame/bugfixes/BUG-123-START \
> svn://olio/sesame/bugfixes/BUG-123-FINISH .
> # Same merge operation to put the fix on the trunk and other branches
I'd do
$ svn merge -rX:Y svn://olio/sesame/bugfixes/BUG-123
were X and Y are the start and end revisions of the branch.
> Couple of points here -- if I just create a bugfix branch, do I need to
> tag the start of it for later merging? This is easier than using something
> like svn log --stop-on-copy to figure out where the branch started.
You anticipated my comments :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre and post bugfix tagging and mixed rev working copies
Posted by Michael Mason <mg...@eskimoman.net>.
On Wed, 1 Dec 2004 kfogel@collab.net wrote:
> 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?
I'll do that, will attach in another mail.
> 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.
I realised this morning that a branch-per-bugfix style is much more the
way this is done in Subversion. Here's what I wrote down:
# start working on a bug fix
svn copy -m "start bugfix branch" \
svn://myserver/myproj/branches/RB-1.0 \
svn://myserver/myproj/bugfixes/BUG-123
svn copy -m "tag start of fix" \
svn://myserver/myproj/bugfixes/BUG-123 \
svn://myserver/myproj/bugfixes/BUG-123-START
# check out code to work on bug
svn checkout svn://myserver/myproj/bugfixes/BUG-123 bug-123
# fix, doing multiple commits
# we're done fixing, now mark the end of the bugfix
svn copy -m "tag end of fix" \
svn://myserver/myproj/bugfixes/BUG-123 \
svn://olio/sesame/bugfixes/BUG-123-FINISH
# Merge the bugfix into release 1.0's branch
cd rb-1.0
svn update
svn merge \
svn://olio/sesame/bugfixes/BUG-123-START \
svn://olio/sesame/bugfixes/BUG-123-FINISH .
# Same merge operation to put the fix on the trunk and other branches
Couple of points here -- if I just create a bugfix branch, do I need to
tag the start of it for later merging? This is easier than using something
like svn log --stop-on-copy to figure out where the branch started.
Thanks for the help!
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre and post bugfix tagging and mixed rev working copies
Posted by kf...@collab.net.
Mike Mason <mg...@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