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:muzu...@gmx.net] Sent: vrijdag 11 januari 2013 09:02 To: Daniel Shahaf; users@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 <danie...@elego.de> An: Roman Kellner <muzu...@gmx.net>, users@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@oldrev bar' excepted)
