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

Re: ci of a previously removed directory fails

From: Keith Richling <keith_richling_at_agilent.com>
Date: 2004-08-20 22:22:17 CEST

Max Bowsher wrote:
> Keith Richling wrote:
>> Max Bowsher wrote:
>>> Keith Richling wrote:
>>>> If I remove a directory and checkin, then move the parent directory and
>>>> checkin, then re-add the removed directory and checkin, then this last
>>>> checkin fails. I have found no way to work around this problem.
>>>> How do
>>>> I perform this last checkin?
>>> Same answer as your previous similar question. Please actually read the
>>> section of the book you were pointed to.
>>> Max.
>> I read the section and I do understand how I created the problem. This
>> question is now that I have a broken working copy how do I fix it. An
>> "svn up" does not work. I can find now way to fix my working copy to
>> allow me to perform the checkin.
> I apologize - the similarity to your previous question led me to not
> looking carefully at this.
> It seems you have stumbled across a fairly major bug in "svn mv".
> If you do a "svn log -v url://to/repos" you will see that the copy of
> exec to act has octually originated from a revision before exec/dir was
> deleted! This was because exec was out-of-date hwen you did the copy.
> The bug is that the client failed to report to the server the absence of
> dir, but retained that absence in the local copy. *BOOM* The server and
> client now disagree, so here is where the problems start. Later you
> re-add "dir". The client is fine with this, because the earlier "dir"
> has vanished from it's memory. However, when you go to commit, the
> re-addition attempts to add an object which already exists in the
> repository. Error.
> You can recover your working copy by doing:
> 1. "svn revert" the scheduled addition of the obstructing item ("dir" in
> this case).
> 2. "mv" (not "svn mv") the now un-versioned obstruction to some
> temporary name.
> 3. Edit .svn/entries in the directory where the obstruction was located.
> Add the attribute-value pair incomplete="true" inside the first <entry
> ... /> tag.
> 4. "svn up". The working copy will now be re-synced with the repository.
> This is clearly a bug - would you like to file it in IssueZilla, or
> shall I?
> Max.

If you do not mind, could you file the bug?

Keith Richling                     |  Agilent Technologies
Email: keith_richling@agilent.com  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 20 22:22:45 2004

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.