You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Robert Segal <rs...@3dna.net> on 2006/01/26 17:58:25 UTC
Troubles updating repository to a stable state
I fear I have become entagled in a web of versioning trouble. Let me review
my woes....
I whom I will refer to as developer A committed some chanages this morning
thinking hey this is great, everything is great. Little did I know that
developer B had committed some changes before I had comitted my changes.
This in itself is fine. When I went to commit my changes I updated to get
the latest changes from developer B then committed my own. The problem is
that as a result of these merges now the application we are working on is in
a broken state. The changes that developer B had committed we're actually
supposed to be committed to a branch he was working on. Unfortunately they
we're commmitted to the trunk instead.
Now I'm trying to figure out how I undo this mess. I have the latest
revision which has my changes but several revisions before that which
contain the trouble making versions. What I would like to do is merge the
state of repository from before all this mess occured with changes made in
the latest revision that has my changes but only the changed files from the
latest revision. I don't want anything in between the last known stable
state and the head revision. Would there be a way to do this? I'm trying
to figure out various schemes of rolling back to a certain state and then
adding the files I have changed. Something like that. Any help would be
greatly appreciated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Troubles updating repository to a stable state
Posted by Robert Segal <rs...@3dna.net>.
Ok I was finally able to sort out a plan that works. Seems that there was
more than one case where a folder was deleted and then re-added under the
same name. What this resulted in was a very frustrated developer. Me. My
solution was to rollback absoloutely everything that had been committed
after the trouble making revision sequentially. Including the proper
changes. A bit time consuming and this means that the correct changes I had
made in the head revision would be removed and I would have to re-add them
but that was a minor price to pay in my mind.
-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com]
Sent: Thursday, January 26, 2006 5:13 PM
To: rsegal@3dna.net
Cc: users@subversion.tigris.org
Subject: RE: Troubles updating repository to a stable state
>>>>> "Robert" == Robert Segal <rs...@3dna.net> writes:
Robert> Thanks for the suggestions Paul. I would agree that your
Robert> process should work but I have another wrench to throw into
Robert> this equation. I am attempting to merge the revision from
Robert> the point where the bad commit was made to just before it was
Robert> made as I believe you suggested Paul. However in my case
Robert> there are multiple versions comitted which are bad. Normally
Robert> I wouldn't have a problem with this. I would assume the
Robert> merge range would be something more along the lines of
Robert> svn merge -r 123:110 http://path/to/repo/trunk
Right. That assumes no one else did any commits in the middle of the
string of bad ones.
(By the way, this is the reason why I emphasize the rule "one task,
ONE commit" in my training. But admittedly the situation can still
occur even if people follow that rule.)
Robert> Just an example of course but you get the idea. The nice
Robert> "wrench" I am introducing is that in that range of wrong
Robert> changes a folder was deleted. I shall say at around version
Robert> 112. Then in revision 114 that folder was readded. So now
Robert> when I go to merge from 123 to 100 I get an error message
Robert> along the lines of...
Robert> "Revision 110 doesn't match existing revision 123 in
Robert> <local-path-to-working-copy>"
Robert> My thought is that SVN is getting confused because this
Robert> folder that was deleted and then readded is actually two
Robert> different folders although it has the same name throughout
Robert> the course of the wrongfully committed revision span.
That sounds right.
Do it with two consecutive merge commands:
svn merge -r 123:114 ...
svn merge -r 114:110 ...
I haven't tried that sort of thing or run into the situation you
describe, but it seems plausible that this should work.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Troubles updating repository to a stable state
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Robert" == Robert Segal <rs...@3dna.net> writes:
Robert> Thanks for the suggestions Paul. I would agree that your
Robert> process should work but I have another wrench to throw into
Robert> this equation. I am attempting to merge the revision from
Robert> the point where the bad commit was made to just before it was
Robert> made as I believe you suggested Paul. However in my case
Robert> there are multiple versions comitted which are bad. Normally
Robert> I wouldn't have a problem with this. I would assume the
Robert> merge range would be something more along the lines of
Robert> svn merge -r 123:110 http://path/to/repo/trunk
Right. That assumes no one else did any commits in the middle of the
string of bad ones.
(By the way, this is the reason why I emphasize the rule "one task,
ONE commit" in my training. But admittedly the situation can still
occur even if people follow that rule.)
Robert> Just an example of course but you get the idea. The nice
Robert> "wrench" I am introducing is that in that range of wrong
Robert> changes a folder was deleted. I shall say at around version
Robert> 112. Then in revision 114 that folder was readded. So now
Robert> when I go to merge from 123 to 100 I get an error message
Robert> along the lines of...
Robert> "Revision 110 doesn't match existing revision 123 in
Robert> <local-path-to-working-copy>"
Robert> My thought is that SVN is getting confused because this
Robert> folder that was deleted and then readded is actually two
Robert> different folders although it has the same name throughout
Robert> the course of the wrongfully committed revision span.
That sounds right.
Do it with two consecutive merge commands:
svn merge -r 123:114 ...
svn merge -r 114:110 ...
I haven't tried that sort of thing or run into the situation you
describe, but it seems plausible that this should work.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Troubles updating repository to a stable state
Posted by Robert Segal <rs...@3dna.net>.
Thanks for the suggestions Paul. I would agree that your process should
work but I have another wrench to throw into this equation. I am attempting
to merge the revision from the point where the bad commit was made to just
before it was made as I believe you suggested Paul. However in my case
there are multiple versions comitted which are bad. Normally I wouldn't
have a problem with this. I would assume the merge range would be something
more along the lines of
svn merge -r 123:110 http://path/to/repo/trunk
Just an example of course but you get the idea. The nice "wrench" I am
introducing is that in that range of wrong changes a folder was deleted. I
shall say at around version 112. Then in revision 114 that folder was
readded. So now when I go to merge from 123 to 100 I get an error message
along the lines of...
"Revision 110 doesn't match existing revision 123 in
<local-path-to-working-copy>"
My thought is that SVN is getting confused because this folder that was
deleted and then readded is actually two different folders although it has
the same name throughout the course of the wrongfully committed revision
span.
Any thoughts how I might get around this? It seems any of my attempts to
rollback end up crashing because the repository has been restructured quite
a bit in the most recent set of revisions.
David Gale wrote:
>Incidentally, you say that you updated and then committed; did you test
>between those two operations? One thing I learned early on was the
>importance of testing whenever I've updated in someone else's code
>changes, just in case of an unflagged (logical) collision.
I would definitely agree this is good practice. Normally I do this but I
believe my brain was slacking at that particular moment and I don't believe
I did this. Oh well now I pay the penalties. Thanks both for your
suggestions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Troubles updating repository to a stable state
Posted by Paul Koning <pk...@equallogic.com>.
I'm not sure if I follow what you were asking, but let me describe
what I think the problem is and how I would deal with it.
1. You have a good repository.
2. User A and B check out.
3. User A does some work (which is good stuff).
4. User B does some work, mistakenly on the wrong branch, commits it.
5. User A does "svn update" (merging in B's changes) and commits the result.
6. Oops, you now have broken code.
What you want is the work of A but not that of B -- in other words,
undo step 4.
Look at the log. Suppose the commit of B was rev 123.
At the top of a working directory for your repository (trunk or the
appropriate branch), do
svn merge -r 123:122 http://path/to/repo/trunk .
That will apply the reverse of the changes made by rev 123 -- in
effect, an "undo" of B's commit. It's possible you will get conflicts
(if so, A is likely to know, since he would have seen the analogous
conflicts during the update at step 5). If so, resolve them, then
commit the result.
You should now have what you want. This is an example of the general
"how to undo something" procedure, which Subversion makes pretty easy
this way.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org