Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAGVGHmu=uunST_eDFju--xQZ3XnOn+QSkjFtEqkdatbMinA+Yg@mail.gmail.com>
References: <CAGVGHmu=uunST_eDFju--xQZ3XnOn+QSkjFtEqkdatbMinA+Yg@mail.gmail.com>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Tue, 22 Nov 2016 09:50:59 +0100
Message-ID: <CAB84uBX4Tta6OK=hXxCb4EwFMkK=d2pUnDN0yWdLG4pcNgXVqQ@mail.gmail.com>
Subject: Re: Adopting unversioned directory on svn up
To: Olaf van der Spek <ml@vdspek.org>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 22 Nov 2016 08:51:30 -0000

On Tue, Nov 22, 2016 at 8:56 AM, Olaf van der Spek <ml@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