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 <rsegal@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
Received on Wed Feb 1 00:24:15 2006