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 09:02:37 CET