On Tue, Nov 22, 2016 at 8:56 AM, Olaf van der Spek <ml_at_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
Received on 2016-11-22 09:51:30 CET