[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Update in excluded directory schedules files for deletion

From: Holger Schmidt <Holger.Schmidt_at_zmdi.com>
Date: Tue, 11 Mar 2014 13:30:37 +0100

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
Received on 2014-03-11 13:31:16 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.