[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: Sun, 25 Aug 2013 11:19:24 +0200

[not cross-posting to users@ as this is a dev@ topic]

On 24.08.2013 23:57, Travis Brown wrote:
> I'd be interested to hear of a single situation where _this_patch_,
> not some theoretical tree conflict resolving AI which bears no
> relation to this patch, does the wrong thing and the wrong thing is
> _worse_ than the existing functionality.

Since your patch does not affect the behaviour with files, you'll get
tree conflicts on any identically-named files, not merge conflicts (see
my build.xml example). I frankly fail to see how that's better than
having one tree conflict on the directory.

Even assuming the ideal situation where the intersection of the contents
of the (unversioned) local tree and the incoming tree is empty (i.e.,
the trees are completely different except for being rooted on a
directory with the same name), so you don't get any tree conflicts on
files, the result will be a union of those contents.

Now for the particular use case that started this whole discussion,
where the unversioned contents consist entirely of generated files,
that's not a problem (barring strange effects on build tools). But for
every other case it is, so you can hardly claim that your patch would
have no adverse consequences, especially as the assumption is that
Subversion would merge the trees silently, without even warning the
user. You could end up with two distinct and perhaps conflicting modules
merged into one, with the extra bonus that your build might not even
fail. Seems like a good way for introducing bugs into the code base. :)

(Not to mention that from the point of view of CM processes and
repeatable builds, this is a nightmare).

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-08-25 11:20:07 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.