Re: Adopting unversioned directory on svn up

On Sat, Dec 3, 2016 at 10:11 PM, Olaf van der Spek <ml_at_vdspek.org> wrote:
> On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
>>> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>>> >> >> For directories it seems like a no-brainer to avoid the conflict.
>>> >> >
>>> >> > Indeed, adding a resolver option for this should not be very difficult.
>>> >>
>>> >> I'd opt for not having a conflict in the first place.
>>> >
>>> > There is a reason the non-conflict behaviour requires the --force option.
>>> > It is perfectly fine for Subversion to be conservative if the alternative
>>> > is to litter all over other people's data.
>>> >
>>> > And this conflict is not very difficult to solve:
>>> >
>>> > When a directory DIR has an "local dir unversioned, incoming dir add upon
>>> > update" conflict, and you want to keep DIR as it was and do not want SVN
>>> > to touch it after all, all you need to do is move DIR out of the working
>>> > copy (with standard operating system tools) to somewhere else and it will
>>> > have been preserved as it was before SVN got involved.
>>> > Then run 'svn revert -R DIR' to put the versioned content in place.
>>> > Note that this solution is not trivial to achieve after update --force
>>> > which might modify unversioned files, requiring the user to edit files
>>> > in DIR back into their original state. This is why --force is not the default.
>>>
>>> Are you sure?
>>> In my experience --force does NOT overwrite existing files.
>>> Not overwriting files is safe and exactly what I want.
>>
>> I am quite sure:
>>
>> $ cd trunk-wc
>> $ ls
>> alpha beta epsilon/ gamma/
>> $ cat epsilon/zeta
>> zeta
>> $ cd ..
>> $ rm -rf trunk-wc
>> $ mkdir -p trunk-wc/epsilon
>> $ echo zzz > trunk-wc/epsilon/zeta
>> $ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
>> A trunk-wc/alpha
>> A trunk-wc/beta
>> E trunk-wc/epsilon
>> E trunk-wc/epsilon/zeta
>> A trunk-wc/gamma
>> A trunk-wc/gamma/delta
>> Checked out revision 2.
>> $ svn diff trunk-wc
>> Index: trunk-wc/epsilon/zeta
>> ===================================================================
>> --- trunk-wc/epsilon/zeta (revision 2)
>> +++ trunk-wc/epsilon/zeta (working copy)
>> @@ -1 +1 @@
>> -zeta
>> +zzz
>
> So what unversioned file was overwritten by --force?
> zeta wasn't modified by the checkout was it?

I think the most annoying consequence of accidentally checking out
over an existing directory, without any conflict detection (if the
--force behaviour would be the default), would be that you cannot
easily undo the operation. You haven't lost any unversioned data, but
you can not easily remove the checkout again and "rollback" to the
state before the checkout.

Suppose you have files a and b locally. And the checkout
"incorporates" a and b (say they become unmodified because they are
the same as the repository version) and adds c, d, e, f, g, ... Oops,
the checkout was accidental. Now how do I remove it again? I don't
know which files were there before and which were added by the
checkout. Now imagine this happening with a complex tree structure
with 10,000 directories and 100,000 files.

So I think it's best not to do this by default.

-- 
Johan