[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

defining obstructions (was: Re: svn commit: r1687029 - /subversion/trunk/subversion/tests/cmdline/mergeinfo_tests.py)

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 24 Jun 2015 08:44:00 +0200

On Tue, Jun 23, 2015 at 11:59:25PM +0000, Bert Huijben wrote:
> Update and merge report ‘obstructed; for different reasons… But are within itself pretty consistent, and the documentation of obstructed in svn_wc.h supports both implementations.

Can you explain how the reasons for reporting an obstruction are different?
I've tried finding the explanation in subversion/include/svn_wc.h but
could not find any.

I believe we should only use 'obstruction' to refer to something that is
unversioned from the point of view of the working copy we're operating in.
Note that this includes sub-directories containing unrelated working copies
which were checked out separately, and thus also externals.

If there are instances of a versioned node of some sort causing an
'obstruction' to be reported, I believe we should change that.

Philip pointed out to me yesterday that before 1.7 a locally added directory
or file could 'obstruct' an incoming newly added directory tree in the 1.6
working copy design, since we could not add the incoming subtree meta data
anywhere but in the subtree itself. This problem is gone now, so I think we
should stop referring to this case as a 'local obstruction vs. incoming add'
and instead call it what it is from the user's point of view, a 'local add
vs incoming add'
Received on 2015-06-24 08:44:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.