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.
> As far as I can see, the only nice way to have versioned files merged with
> unversioned files is to use checkout/update with the --force option which
> avoids the tree conflict in the first place. (Running 'svn add DIR' after
> 'svn revert -R DIR' will also merge the files, but schedules an undesirable
> replacement as well.) So this is something the conflict resolver could handle
> in a better way than existing svn commands can.
> However, I'm not very sure how well merging of arbitrary versioned and
> unversioned content generally works out in practice. Is this really more
> useful than one of the other two solutions?
>
> In summary, these are the options the conflict resolver could offer:
> 1) move DIR to another place and restore its versioned content
> 2) discard all unversioned content and put versioned content in place
> 3) merge versioned and unversioned content where paths overlap (like --force)
> Nothing new here, expect the ability to get the same behaviour as with
> update --force after the conflict has been flagged because the user really
> wants to merge the files (why?)
Suppose only directories 'conflict', then there's no danger of
overwriting data and the conflict seems to complicate stuff without
real benefit.
Suppose a file 'conflicts'.. it seems trivial to preserve the existing
file and not mark anything as conflicted. The file will / might show
as modified but that's no problem. No data gets lost.
How do such 'conflicts' happen?
Sometimes a file gets copied / uploaded via SFTP.
Or in the case of me versioning some files in /etc, the system / pkg
installer already created some directories and I'm merely adding some
not yet existing files into them.
> and forgot to use --force.
I wasn't aware of --force before asking this question. --force is
usually used for dangerous stuff as well.
> The biggest advantage of offering such options is that users would not
> have to figure out the resolution steps by themselves.
--
Olaf
Received on 2016-12-03 18:42:28 CET