On Fri, Jan 11, 2013 at 09:01:56AM +0100, Roman Kellner wrote:
> 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?
We've long moved past the entries file format. We aren't even fixing
bugs in the 1.6 WC implementation anymore (unless they're security
or data corruption fixes). The current Subversion 1.7 working copy
works in entirely different ways, and we will stop supporting 1.6
entirely when 1.8 is released. I would not recommened you rely on the
entries file format in any way in your script/product. Use the
svn status --xml comand or the Subversion APIs instead, which can
be accessed from several programming languages (see here for API
docs: http://subversion.apache.org/docs/#api)
FWIW here's the documentation of the 'deleted' field, from the file
https://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_wc/README
deleted:
A boolean: true if this entry is deleted in its revision but exists
in its parent's revision. This is necessary because updates are
not atomic: different bits of a working copy can be updated to
different revisions at different times, and it's possible that
this entry may be updated to a more recent revision (R) than its
parent's revision (P). If this entry is deleted in R, and the
parent is trying to report its own state (based on P) to the
repository, the parent cannot simply claim to be at P; the parent
must also indicate that this particular entry is deleted because it
is at R.
So this flag is used in the 1.6 working copy to represent mixed-revision
working copies, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
> <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),
What is MTPE/MWT/MSSCCI? Please provide some context or a least a
reference. I'm afraid I don't really understand what you are talking
about. It seems to be some tool. What is this tool doing and why is
it managing a Subversion working copy? And why would it want to fiddle
with Subversion's meta data in .svn directories?
> 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).
This is what mixed-revisions do. You need to update the parent folder
of the file as well to get rid of the 'deleted' flag. However the file
should disappear from the working copy (i.e. it should disappear from
disk). If it doesn't, then please try Subversion 1.7 to see if the
problem has been fixed there.
>
> 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.
In what way does this part relate to the above?
Please explain more. What problem are you trying to solve?
>
> Use case:
> MTPE/MWT sync.
Received on 2013-01-11 10:59:39 CET