This issue sounds like a combination of issues #2763 and #3569.
The ‘svn up --depth empty’ in 1.6 triggers issue #3569:
http://subversion.tigris.org/issues/show_bug.cgi?id=3569 ‘svn update --depth <DEPTH> allows making a working copy incomplete’
While #2763 handles some similar cases in copies:
http://subversion.tigris.org/issues/show_bug.cgi?id=2763 ‘del -> ci -> cp = missing directory?’
Both issues were fixed for 1.7 and are very hard to fix for 1.6 and earlier, as the fix for both relies on the additional layers in WC-NG.
The easy fixes you might try break in other cases, as the data to do the right thing is just not stored in the working copy in 1.6.
Bert
From: Roman Kellner [mailto:muzungu_at_gmx.net]
Sent: vrijdag 11 januari 2013 09:02
To: Daniel Shahaf; users_at_subversion.apache.org
Subject: Re: branching WC folder fails with files marked as deleted
Hello Daniel, hello Stefan
Sorry for the empty email. Dont know what happened to the web email.
I guess I found the issue and implemented the following feature in our MSSCCI wrapper.
If you can confirm that, when I find a "deleted" line in the .svn/entries file to a WC controlled file as shown below, then the file was only deleted in the WC and is marked for deletion in the repo which will be done with the next commit. Is this the exact meaning of "deleted" the the WC control area entries file? And there is no other meaning?
<ff>
c1cf5a64-afc7-45b3-963c-f8ce2ed2cecf.mtx
file
124877
<some emty lines>
< : >
<some emty lines>
deleted
<ff>
Feature justification:
When a file is added to the repo, sync'd
(checked out/updated) to the working copy (by MTPE/MWT/MSSCCI),
later the same file is deleted from the repo and the working copy
sync'd (by MTPE/MWT/MSSCCI) again, this file is NOT 'updated'
(svn up file) which with SVN would remove the file from the working
copy but instead is (falsely) 'deleted' (svn del file) which removes
the working copy file and marks this file as scheduled to be deleted
in the working copies control area (.svn/entries).
Feature:
A 'SccGet' immediately following a 'SccPopulateList' where the
folders (SccPopList) and the file folders (SccGet) do match between
the two calls, will trigger a user dialogue asking whether to
update the folders instead of the file list passed to SccGet.
The feature can be controlled by setting the list size either
to <= 0 to disabled, or to > 0 to enable and configure the max.
file / folder list length in the dialog.
Use case:
MTPE/MWT sync.
-------- Original-Nachricht --------
Datum: Thu, 10 Jan 2013 00:33:38 +0200
Von: Daniel Shahaf <danielsh_at_elego.de>
An: Roman Kellner <muzungu_at_gmx.net>, users_at_subversion.apache.org
Betreff: Re: branching WC folder fails with files marked as deleted
Stefan Sperling wrote on Wed, Jan 09, 2013 at 14:21:06 +0100:
> On Wed, Jan 09, 2013 at 02:02:32PM +0100, Roman Kellner wrote:
> > - Now the user-A needs to branch his WC and gets the following error
> > message on commit
> > (the file shown in the error message is the one that was created and later
> > deleted):
>
> Please do not attach images when posting to a mailing list.
> Instead, copy/paste the error message into your email in plain text.
>
> > I would consider this a bug. Why does the client not simply ignore deleted
> > marked file entries?
>
> Subversion represents renames as a copy and a delete operation.
>
> Subversion does not allow you to commit deletions of outdated items,
> because this would prevent some tree conflicts from being detected.
I don't think one needs to understand tree conflicts to understand why
deleting out of date files is prevented. You can't delete a file that
has been committed to after you checked it out for the same reason you
can't modify such a file: because allowing you to go through would lead
to silently discarding the changes were done made in the newer revision
that your wc doesn't have.
('svn cp foo_at_oldrev bar' excepted)
Received on 2013-01-11 13:43:03 CET