You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by tr...@clayst.com on 2005/06/06 16:41:55 UTC
Removing Erroneous Revisions
So if I committed a bunch of stuff that I shouldn't have committed (due
to a dumb error on my part), then merged it to another branch, and
committed that, is there any way to undo it all -- to remove several
revisions off the head of the repository -- other than something with
svndump?
If I do have to use svndump, how do I remove a revision? The FAQs
cover removing a file but not a revision.
Or, can I just delete the revision subdirectories that I don't want, if
my working copies are restored to a date before that? It's an FSFS
repository?
Or is this some option that's staring me in the face and I just didn't
see it?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by tr...@clayst.com.
On 8 Nov 2005 Gavin Lambert wrote:
> Well, it's better to first commit your changes from the dev WC to the
> dev branch (making r31 in dev). *After* that you merge r28:31 from live
> into dev and resolve conflicts, then commit again, making r32. Then if
> you're happy terminating the branch, you can switch to live, merge
> r28:32 from dev to live, and commit r33.
>
> That way it's more obvious what changes the merge is making, and you can
> back it out if something went fubar.
Fair enough. Thanks for the tip.
> > But what about this:
> >
> > At r27 the two branches are synchronized (last merge)
> > 'Live' branch has some changes committed in r28 and r30
> > 'Dev' branch has some changes committed in r29 and r31
> > 'Dev' branch has also been updated (WC only)
> > Merge live changes from r28:30 to dev, should work as above
> > Commit dev as r32
> >
> > Now, how do I get the dev changes back into the live branch? What
> > revisions do I merge? The interlacing makes it very confusing.
>
> 1. Commit dev (r32)
> 2. Merge r28:32 from live into your dev WC (HEAD is 32)
> 3. Resolve any conflicts, make sure everything still works ok
> 4. Commit dev (r33)
> 5. Switch to your live branch
> 6. Merge r28:33 from dev into your live WC (HEAD is 33)
> 7. Make sure things are still ok
> 8. Commit live (r34)
>
> (In step 2, since r29 and r31 only contained changes to the dev branch,
> there won't be any modifications in the live branch for those revisions.
> So merging them is a no-op and quite safe.)
This makes sense but what concerns me is your step 6. r28:33 on the
dev branch contains all of the r28:32 changes from the live branch so
they are being applied back to live. This seems like a recipe for
problems but I am not sure I can mentally construct a good enough set
of test cases to see if that hunch is right or wrong.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth trlists@clayst.com <ma...@clayst.com>:
> However ... imagine this scenario:
>
> At r27 the two branches are synchronized (last merge)
> 'Live' branch has some changes committed in r28 - r30
> 'Dev' branch has also been updated (WC only)
> Merge live changes from r28:30 to dev -- this gets bug fixes
> into the dev branch -- and resolve any conflicts
> Commit dev as r31
>
> Here I think it's simple -- if dev has not been committed since r27 I
> can just merge dev changes from r27:31 back to live. Right?
Well, it's better to first commit your changes from the dev WC to the
dev branch (making r31 in dev). *After* that you merge r28:31 from live
into dev and resolve conflicts, then commit again, making r32. Then if
you're happy terminating the branch, you can switch to live, merge
r28:32 from dev to live, and commit r33.
That way it's more obvious what changes the merge is making, and you can
back it out if something went fubar.
> But what about this:
>
> At r27 the two branches are synchronized (last merge)
> 'Live' branch has some changes committed in r28 and r30
> 'Dev' branch has some changes committed in r29 and r31
> 'Dev' branch has also been updated (WC only)
> Merge live changes from r28:30 to dev, should work as above
> Commit dev as r32
>
> Now, how do I get the dev changes back into the live branch? What
> revisions do I merge? The interlacing makes it very confusing.
1. Commit dev (r32)
2. Merge r28:32 from live into your dev WC (HEAD is 32)
3. Resolve any conflicts, make sure everything still works ok
4. Commit dev (r33)
5. Switch to your live branch
6. Merge r28:33 from dev into your live WC (HEAD is 33)
7. Make sure things are still ok
8. Commit live (r34)
(In step 2, since r29 and r31 only contained changes to the dev branch,
there won't be any modifications in the live branch for those revisions.
So merging them is a no-op and quite safe.)
I'm fairly sure that this is the correct procedure, anyway :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by tr...@clayst.com.
On 7 Nov 2005 Gavin Lambert wrote:
> Quoth trlists@clayst.com <ma...@clayst.com>:
> > (1) Merge changes from live into dev first so that dev picks
> > up the bugfixes. Then merge from dev back to live to update the
> > trunk with the new features. Will this work? How would I choose
> > which revisions to merge for the second merge?
>
> This is the typical approach, AFAIK. The process is explained in the
> SVN book, but AFAIK you basically just need to remember which revision
> was HEAD in 'live' when you branched (or last merged from it). Then you
> can merge in any changes made since then. Typically you do this by
> noting it in the comments for the branch.
Thanks for the response.
That part I've done before. It's a bit confusing because the book
mentions "stop on copy" but that methhod doesn't work if you are
continuously maintaining two branches and resynchronizing them from
time to time. There is no copy in that scenario except the original
one. But I do have the comments when I merged that show what revisions
were merged.
However ... imagine this scenario:
At r27 the two branches are synchronized (last merge)
'Live' branch has some changes committed in r28 - r30
'Dev' branch has also been updated (WC only)
Merge live changes from r28:30 to dev -- this gets bug fixes
into the dev branch -- and resolve any conflicts
Commit dev as r31
Here I think it's simple -- if dev has not been committed since r27 I
can just merge dev changes from r27:31 back to live. Right?
But what about this:
At r27 the two branches are synchronized (last merge)
'Live' branch has some changes committed in r28 and r30
'Dev' branch has some changes committed in r29 and r31
'Dev' branch has also been updated (WC only)
Merge live changes from r28:30 to dev, should work as above
Commit dev as r32
Now, how do I get the dev changes back into the live branch? What
revisions do I merge? The interlacing makes it very confusing.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth trlists@clayst.com <ma...@clayst.com>:
> (1) Merge changes from live into dev first so that dev picks
> up the bugfixes. Then merge from dev back to live to update the
> trunk with the new features. Will this work? How would I choose
> which revisions to merge for the second merge?
This is the typical approach, AFAIK. The process is explained in the
SVN book, but AFAIK you basically just need to remember which revision
was HEAD in 'live' when you branched (or last merged from it). Then you
can merge in any changes made since then. Typically you do this by
noting it in the comments for the branch.
> (2) Use svn diff to find the changes in the live branch that are not
> yet in dev and make them manually, then merge changes only one way,
> from dev to live.
That's pretty much the same as #1, except that you're doing the grunt
work yourself :)
> (3) Merge from dev to live then delete the dev WC and get a
> new one off the live branch as the base for future development.
This won't work if people other than yourself are committing things to
'live'. Or if you're committing things to 'live' from outside the dev
branch. Which sounds like the case if you're worried about stray bugfix
code in the first place.
> #3 seems like the cleanest approach but it is complicated by the fact
> that I have bunch of unversioned stuff in the dev deirectories that I
> wouldn't want to lose, so I can't just delete the WC and do another
> checkout. Is there any way to remove all the versioned files from a
> directory tree, leaving only what is unversioned?
svn switch would probably work. Either switching to the latest branch
or to an empty folder. But I don't think #3 is the way to go anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Merge One Direction or Both?
Posted by tr...@clayst.com.
Folks ...
I have a situation that seems fairly typical:
branch 'live' could be called the trunk, it's the live code and I
make small bug fixes and revisions here, committed each time I
am ready to update the site (it's a web project)
branch 'dev' is where I do major development work on new features
When I complete some work in dev I have a couple of options:
(1) Merge changes from live into dev first so that dev picks up the bug
fixes. Then merge from dev back to live to update the trunk with the
new features. Will this work? How would I choose which revisions to
merge for the second merge?
(2) Use svn diff to find the changes in the live branch that are not
yet in dev and make them manually, then merge changes only one way,
from dev to live.
(3) Merge from dev to live then delete the dev WC and get a new one off
the live branch as the base for future development.
Any tips here?
#3 seems like the cleanest approach but it is complicated by the fact
that I have bunch of unversioned stuff in the dev deirectories that I
wouldn't want to lose, so I can't just delete the WC and do another
checkout. Is there any way to remove all the versioned files from a
directory tree, leaving only what is unversioned?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Removing Erroneous Revisions
Posted by Dale Worley <dw...@pingtel.com>.
> From: trlists@clayst.com [mailto:trlists@clayst.com]
>
> This looks pretty easy, given that it is the last half dozen commits
> that I want to reverse, i.e. not a subset just everything done since
> rev x. Am I missing anything?
The one change I'd suggest is replacing "HEAD" with the number of the rev in
question. In practice, it probably doesn't matter, but in principle, HEAD
can change at any moment. But if you use numerical revs, the operation Does
What You Want even if other developers are checking in further changes to
both branches as you work! (That's the cool thing about Subversion, if you
phrase your commands right, it will do what you want under even adverse
conditions.)
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Removing Erroneous Revisions
Posted by tr...@clayst.com.
On 6 Jun 2005 Dale Worley wrote:
> Generally, you want to do a fix that messy with a careful set of "undo
> merges". Check out a sandbox of a branch, then:
>
> svn merge -r101:100 .
> svn merge -r29:28 .
>
> etc. to reverse the changes you want to.
I think this will be easy because i can just reverse merge HEAD:nn
where nn is the last good revision (it was the same on all branches).
But if I did the original commits this way:
cd /path/to/brancha_wc
svn commit -m ...
svn log --stop-on-copy ==> copy was at rev cc
cd /path/to/branchb_wc
svn update
svn merge -r cc:HEAD /path/to/repos/brancha
svn commit -m ...
then can I reverse it as simply as this, where nn is the last good rev:
cd /path/to/brancha_wc
svn merge -r HEAD:nn /path/to/repos/brancha
svn commit -m ...
cd /path/to/branchb_wc
svn merge -r HEAD:nn /path/to/repos/branchb
svn commit -m ...
This looks pretty easy, given that it is the last half dozen commits
that I want to reverse, i.e. not a subset just everything done since
rev x. Am I missing anything?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Removing Erroneous Revisions
Posted by Dale Worley <dw...@pingtel.com>.
> From: trlists@clayst.com [mailto:trlists@clayst.com]
>
> So if I committed a bunch of stuff that I shouldn't have
> committed (due
> to a dumb error on my part), then merged it to another branch, and
> committed that, is there any way to undo it all -- to remove several
> revisions off the head of the repository -- other than something with
> svndump?
Generally, you want to do a fix that messy with a careful set of "undo
merges". Check out a sandbox of a branch, then:
svn merge -r101:100 .
svn merge -r29:28 .
etc. to reverse the changes you want to. Check that in, then run and debug
it, then check in extra changes you needed to cope with the remove merges.
(It's best to commit the undo merges alone in one revision, so you can later
distinguish which changes are the mechanical undo's and which are the
human-provided adaptations.)
If you made a change in one branch that you want to remove, and then merged
that change with a bunch of others to a second branch, it's probably best to
do the undo on the first branch, then merge that change to the second
branch, which should leave the second branch in the state you want.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org