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

Re: Switching

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 24 Aug 2013 22:04:53 +0200

On 24.08.2013 21:26, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>>> Don't forget that it was subversion, not the user, that created the
>>> directory and abandoned it in the first place.
>> If a previously versioned directory is left behind unversioned, that
>> means there are unversioned (aka obstructing) nodes within the
>> directory, such as files created during a build. Those files could
>> not have been created by svn.
>>
>> I hope that we will eventually extend tree conflict handling to the
>> point where it makes these kinds of situations trivial to resolve,
>> even for novice users. svn should interactively offer a set of
>> reasonable courses of action, such as removing the unversioned nodes,
>> or moving them to a special lost+found area, or something else that
>> allows incoming versioned nodes to be created in their place.
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict. There seems to be confusion about what is
> actually needed to solve the OP's original problem and to make svn
> switch symmetric. I've attached a simple patch which solves the issue in
> the method that I proposed.

I already explained at length why this solution is absolutely the wrong
approach. It solves a small subset of cases at the cost of causing
serious grief to users in the majority of cases. Let's please just stop
discussing this approach because it is not viable.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-08-24 22:05:32 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.