> -----Original Message-----
> From: Holger Schmidt [mailto:holger.schm...@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
