On Tue, Nov 22, 2016 at 8:56 AM, Olaf van der Spek <m...@vdspek.org> wrote: > Hi, > > How does one adopt / merge the update from the repo into local > unversioned directories? > Using R marks the directory for deletion. > > # svn up /etc > Updating '/etc': > C /etc/php5 > A /etc/php5/cli > A /etc/php5/cli/conf.d > A /etc/php5/cgi > A . > Updated to revision 55. > Tree conflict on '/etc/php5' > > local dir unversioned, incoming dir add upon update > Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h > > (r) - accept current working copy state > (p) - resolve the conflict later [postpone] > (q) - postpone all remaining conflicts > (h) - show this help (also '?') > Words in square brackets are the corresponding --accept option arguments. > > Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
When I know beforehand that I have a local unversioned directory that maps to a repos-directory that will be incoming when I update, I use the '--force' option for 'svn up'. That avoids the tree conflicts, and sort of "integrates" the existing files into your working copy. >From 'svn help update': [[[ --force : handle unversioned obstructions as changes ]]] During the update you'll get 'E' notifications (for "Existed") for all the items that already exist. Your local files will not be overwritten by the repos-incoming version. After the update, when you run 'svn status', some files might show up as (M)odified (if they were different locally from the repos-incoming version), or not show up if they were identical. In your situation, after having already run the update, I'm not sure what's the best course of action. If it's a separate, new working copy, you might just throw away the '.svn' directory and start over (without touching / losing your local files). If it's part of a larger working copy ... not sure (definitely not "revert" without making a backup copy of your local files, or you might lose local uncommitted changes). -- Johan
