Update in excluded directory schedules files for deletion

[Holger Schmidt <Ho...@zmdi.com>]

Hi,

Can someone please look at this issue, I think it is a bug.  I have a 
working copy with some directories, some have private files in them.  I 
don't need one of the directories and exclude it from the working copy 
with "svn up --set-depth=exclude".  The directory remains because there 
were private files.  If I change into the excluded directory I can query 
the status and update!  The update reports a tree conflict.  If I choose 
"mark resolved" the directory is scheduled for deletion.  Is this 
intended behavior?  I would expect that an excluded directory is like a 
private directory, i.e. no status and update is possible.  I think it is 
dangerous if an update schedules something for deletion.  It's an 
update, not a remove.  Tested with version 1.8.8 compiled on 
x86_64-unknown-linux-gnu.

Try these commands:

svnadmin create repo
svn co file://`pwd`/repo wc
svn mkdir wc/dir
echo a > wc/dir/file1
svn add wc/dir/file1
svn ci -m "Added data." wc
cd wc/
echo b > dir/file2
svn up --set-depth=exclude dir
cd dir/
svn st -u
svn up
svn ci


Thanks,
Holger

Re: Update in excluded directory schedules files for deletion

[Holger Schmidt <Ho...@zmdi.com>]

On 10.03.2014 13:19, Bert Huijben wrote:
> I think I would call this expected behavior... and I will try to explain
> why.
>
> You are forgetting one very important detail in getting to this state: You
> got a tree conflict.
>
> The 'svn up' on an excluded directory is what you would do to reintroduce
> the excluded directory in your working copy. But this is not possible,
> because you still have this directory locally. We call this a "local
> obstruction"
>
> The exclude operation left unversioned files and warned you about this...
>
> Then the update brings back nodes, but can't place them in the working copy,
> because there is an unversioned obstruction.
>
> As we want updates to always complete their operation, we complete the
> update 'shadowed', but explicitly state that whatever is in your working
> copy doesn't match what the repository thinks you have. And the way to do
> this is mark a tree conflict, and mark as deleted what was in the
> repository.
> (In some ways it would be nice if we had an 'obstruction conflict' for
> this... but that is essentially just a tree conflict variant)
>
>
> This way you can resolve the tree conflict locally without accessing the
> repository.
>
> The problem here is that while Subversion can't do much more than offering
> to resolve the conflict by just removing it... but that is not how you
> should resolve this specific kind of tree conflict.
>
>
> I would recommend moving the unversioned directory away and calling
> revert...
>
>
> 	Bert

Hi Bert,

Thank you for the very good explanation.  In my version I just get "D 
  dir" from the exclude operation, it doesn't warn about unversioned files.

That basically means that "exclude" does not mean "absent, not there, 
not considered" as I thought.  It more means "somewhat excluded, might 
be absent, like a working copy if present".  That wasn't clear to me.

So far I though an "svn update" (without --set-depth) synchronizes my 
working copy with the repository.  The people around me even use the 
option --force in case of tree conflicts.  But in this case it 
synchronizes the meta-data with the working copy, sort of.  It will be 
hart to teach everyone that this is intended behavior.

Thanks,
Holger

RE: Update in excluded directory schedules files for deletion

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Holger Schmidt [mailto:Holger.Schmidt@zmdi.com]
> Sent: maandag 10 maart 2014 09:19
> To: users@subversion.apache.org
> Cc: Holger Schmidt
> Subject: Re: Update in excluded directory schedules files for deletion
> 
> On 03.03.2014 16:26, Holger Schmidt wrote:
> > Hi,
> >
> > Can someone please look at this issue, I think it is a bug. I have a
> > working copy with some directories, some have private files in them. I
> > don't need one of the directories and exclude it from the working copy
> > with "svn up --set-depth=exclude". The directory remains because there
> > were private files. If I change into the excluded directory I can query
> > the status and update! The update reports a tree conflict. If I choose
> > "mark resolved" the directory is scheduled for deletion. Is this
> > intended behavior? I would expect that an excluded directory is like a
> > private directory, i.e. no status and update is possible. I think it is
> > dangerous if an update schedules something for deletion. It's an update,
> > not a remove. Tested with version 1.8.8 compiled on
> > x86_64-unknown-linux-gnu.
> >
> > Try these commands:
> >
> > svnadmin create repo
> > svn co file://`pwd`/repo wc
> > svn mkdir wc/dir
> > echo a > wc/dir/file1
> > svn add wc/dir/file1
> > svn ci -m "Added data." wc
> > cd wc/
> > echo b > dir/file2
> > svn up --set-depth=exclude dir
> > cd dir/
> > svn st -u
> > svn up
> > svn ci
> 
> Hi,
> 
> Was someone able to reproduce this?  Would you consider it to be a bug?

I think I would call this expected behavior... and I will try to explain
why.

You are forgetting one very important detail in getting to this state: You
got a tree conflict.

The 'svn up' on an excluded directory is what you would do to reintroduce
the excluded directory in your working copy. But this is not possible,
because you still have this directory locally. We call this a "local
obstruction"

The exclude operation left unversioned files and warned you about this...

Then the update brings back nodes, but can't place them in the working copy,
because there is an unversioned obstruction.

As we want updates to always complete their operation, we complete the
update 'shadowed', but explicitly state that whatever is in your working
copy doesn't match what the repository thinks you have. And the way to do
this is mark a tree conflict, and mark as deleted what was in the
repository.
(In some ways it would be nice if we had an 'obstruction conflict' for
this... but that is essentially just a tree conflict variant)


This way you can resolve the tree conflict locally without accessing the
repository. 

The problem here is that while Subversion can't do much more than offering
to resolve the conflict by just removing it... but that is not how you
should resolve this specific kind of tree conflict.


I would recommend moving the unversioned directory away and calling
revert...


	Bert

Re: Update in excluded directory schedules files for deletion

[Holger Schmidt <Ho...@zmdi.com>]

On 03.03.2014 16:26, Holger Schmidt wrote:
> Hi,
>
> Can someone please look at this issue, I think it is a bug. I have a
> working copy with some directories, some have private files in them. I
> don't need one of the directories and exclude it from the working copy
> with "svn up --set-depth=exclude". The directory remains because there
> were private files. If I change into the excluded directory I can query
> the status and update! The update reports a tree conflict. If I choose
> "mark resolved" the directory is scheduled for deletion. Is this
> intended behavior? I would expect that an excluded directory is like a
> private directory, i.e. no status and update is possible. I think it is
> dangerous if an update schedules something for deletion. It's an update,
> not a remove. Tested with version 1.8.8 compiled on
> x86_64-unknown-linux-gnu.
>
> Try these commands:
>
> svnadmin create repo
> svn co file://`pwd`/repo wc
> svn mkdir wc/dir
> echo a > wc/dir/file1
> svn add wc/dir/file1
> svn ci -m "Added data." wc
> cd wc/
> echo b > dir/file2
> svn up --set-depth=exclude dir
> cd dir/
> svn st -u
> svn up
> svn ci

Hi,

Was someone able to reproduce this?  Would you consider it to be a bug?

Thanks,
Holger