You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Roman Kellner <mu...@gmx.net> on 2013/01/09 14:02:32 UTC
branching WC folder fails with files marked as deleted
Hi
A user (I will call him user-A) of ours encountered the following issue
with our SVN environment:
- SVN server: 1.5.2
- SVN client: TortoiseSVN 1.6.16 (svn 1.6.17)
- user-A checked out the folder '_mt' with a number of file
- user-A then worked with the IDE which only handles (updates, deletes,
checks out etc.) the files in the folder but not the folder itself (the IDE
uses the SCC2SVN client PushOk).
- Meanwhile user-B created a new file in the '_mt' folder in the repo,
user-A checked out/updated to his WC.
- Later user-B deleted the file again in the repo, which user-A updated
into his WC. The created and deleted file(s) where added to the user-A's WC
entries file and marked as "deleted". In the user-A WC this file was
deleted as one would expect.
- 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):
- Updating the '_mt' folder with the setting --depth empty did remove all
the files from the '_mt' folder and was therefore no help.
- Generally updating the the WC folder is unwanted, since user-A needed to
branch the current state of his WC.
- Here is what I did (which is an evil hack):
I remove all file entries in the .svn/entries file that where marked
"deleted" (thanks to still using a 1.6.x client), and the branch could be
created.
I would consider this a bug. Why does the client not simply ignore deleted
marked file entries? I also assume that this is not a TotroiseSVN bug but a
general svn bug.
I further assume that if it is a bug the 1.6.x series is no longer
maintained and a bugfix in 1.6.x rather unrealistic (unless I do it
myself)?
Is this bug known in 1.7.x too and has it been solved?
Updating to 1.7.x is not really wished but if that is the only solution to
it we probably will have to do.
Does anyone know that bug? Can anyone make a statement.
Thanks
Roman
Re: branching WC folder fails with files marked as deleted
Posted by Philip Martin <ph...@wandisco.com>.
"Roman Kellner" <mu...@gmx.net> writes:
> 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?
'deleted' in the entries file represents
svn_wc_entry_t.deleted=TRUE
and is different from 'delete' which represents
svn_wc_entry_t.schedule=svn_wc_schedule_delete
'delete' is when a file in the WC is marked for deletion at the next
commit. 'deleted' is when an entry is not present in the working copy
but would be expected given the revision of the parent.
So after
svn rm f
f is 'delete' and after
svn ci
f is 'deleted'
and after
svn up
f is no longer in .svn/entries.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: branching WC folder fails with files marked as deleted
Posted by Bert Huijben <be...@qqmail.nl>.
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@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 <da...@elego.de>
An: Roman Kellner <mu...@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)
Re: branching WC folder fails with files marked as deleted
Posted by Stefan Sperling <st...@apache.org>.
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.
Re: branching WC folder fails with files marked as deleted
Posted by Roman Kellner <mu...@gmx.net>.
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 <da...@elego.de>
> An: Roman Kellner <mu...@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)
>
Re: branching WC folder fails with files marked as deleted
Posted by Roman Kellner <mu...@gmx.net>.
Re: branching WC folder fails with files marked as deleted
Posted by Daniel Shahaf <da...@elego.de>.
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)
Re: branching WC folder fails with files marked as deleted
Posted by Stefan Sperling <st...@apache.org>.
On Wed, Jan 09, 2013 at 08:52:37AM -0500, Nico Kadel-Garcia wrote:
> I *do* hope that the new "svn mv" architecture will not be confused by this.
>
> svn cp A B
> svn cp A C
> scn cp A D
> svn rm A
The above sequence using cp and rm will keep working as it did before.
If you use "svn mv" you'll have to commit both sides of the move in
the same commit. Else the commit fails.
Currently it behaves like this in the trunk code (1.8-to-be):
$ svn mv alpha alpha2
A alpha2
D alpha
$ svn status
D alpha
> moved to alpha2
A + alpha2
> moved from alpha
$ svn commit -m "just one side of the move" alpha
svn: E200009: Commit failed (details follow):
svn: E200009: Cannot commit '/tmp/svn-sandbox/trunk/alpha' because it was moved to '/tmp/svn-sandbox/trunk/alpha2' which is not part of the commit; both sides of the move must be committed together
Re: branching WC folder fails with files marked as deleted
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Jan 9, 2013 at 8:21 AM, Stefan Sperling <st...@apache.org> wrote:
> Now, you might be wondering why I'm talking about renames rather than
> the deletion of an item, and how this still relates to your particular
> problem case. This is because Subversion generally cannot yet tell the
> difference between the following cases during conflict detection:
>
> svn mv A B
>
> and:
>
> svn copy A B
> svn rm A
>
> and:
>
> svn rm A
It's an awkward problem. I ran into intense screaming from someone
using "git2svn" when I did something like that in 2 different commits,
doing this:
svn copy A B
# Editing B to work in the new location
svn commit B
and then, in a second commit, doing:
svn rm A
Man, did they get upset. It cofused their tools to analyze and compare
change logs, which they expected to match in very fine detail between
the Subversion setup, and that person's own ocal git-svn setup. It was
analyzed correctly as two separate steps only when they hand-tuned
their git setup (I wish I remembered the exact details!)
I *do* hope that the new "svn mv" architecture will not be confused by this.
svn cp A B
svn cp A C
scn cp A D
svn rm A
That really is a different operation than an "svn mv", and it could be
tricky to detect and analyze correctly.
Re: branching WC folder fails with files marked as deleted
Posted by Stefan Sperling <st...@apache.org>.
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.
Please forget your particular problem case for a minute, and consider
this instead:
User 1: svn mv A B
User 2: svn mv A C
User 1: svn commit
User 2: svn commit
The second commit must fail so that User 2 is forced to update the
working copy. This will cause a tree conflict to be flagged, to force
User 2 to think about what to do about the conflict (A cannot be renamed
to two different names -- User 1 and User 2 must agree on a new name
or the rename should be undone).
Subversion 1.5 would allow this commit, but as of Subversion 1.6 this
was changed to avoid a gap in tree conflict detection.
Also, it was possible to create empty revisions by committing the deletion
of something that was already deleted. This is no longer possible as of 1.6.
Does that make sense?
Now, you might be wondering why I'm talking about renames rather than
the deletion of an item, and how this still relates to your particular
problem case. This is because Subversion generally cannot yet tell the
difference between the following cases during conflict detection:
svn mv A B
and:
svn copy A B
svn rm A
and:
svn rm A
Which is going to be addressed in future releases (1.8 and beyond).
I hope the behaviour of future releases will be less and less confusing
as we make further progress on this problem. The current behaviour
can be confusing, unfortunately :-/