On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <s...@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
