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

RE: Troubles updating repository to a stable state

From: Robert Segal <rsegal_at_3dna.net>
Date: 2006-02-01 00:13:12 CET

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

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