subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <jcor...@gmail.com>
Subject Re: Adopting unversioned directory on svn up
Date Wed, 23 Nov 2016 11:36:26 GMT
On Tue, Nov 22, 2016 at 4:31 PM, Olaf van der Spek <ml@vdspek.org> wrote:
> On Tue, Nov 22, 2016 at 9:50 AM, Johan Corveleyn <jcorvel@gmail.com> wrote:
>> 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
>> ]]]
>
> Nice, how come the interactive interface doesn't provide this option?
> Or for it to be the default, especially for directories themselves?

(Please keep the list in cc, unless you explicitly want to private-mail me)

You mean: why can't the interactive conflict resolution (after the
update has been run, and tree conflicts for the entire subtree were
encountered) not do the same as what 'svn up --force' would have done?

I'm not sure, but I think technically it's different for the conflict
resolver than for the update driver. The conflict resolver might not
have the same information at that point anymore, or not the same
capabilities. But I'm just guessing here.

As a matter of fact, right now work is ongoing on trunk for improved
tree conflict resolution for SVN 1.10 (if you're interested, you might
want to follow the dev@ list). I'm not sure if the trunk version of
the conflict resolver would have offered this capability (or if it
will still grow this capability).

Maybe Stefan Sperling (in cc) or others working on the tree conflict
resolver have more insight on this ...?

-- 
Johan

Mime
View raw message