[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: Paul Koning <pkoning_at_equallogic.com>
Date: 2006-01-26 23:13:03 CET

>>>>> "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.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 26 23:15:07 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.