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

Re: Vendor Branch Here

From: Gavin Lambert <tsvn_at_mirality.co.nz>
Date: Thu, 17 Oct 2013 12:00:17 +1300

On 17/10/2013 06:13, Quoth Stefan Küng:
>> Presumably it does not preserve local edits either (as I can't see how
>> it could without having a reference unmodified copy of the previous
>> vendor drop). Isn't this the most important feature of vendor branches?
> It's for vendor branches, which should not have local modifications.
> IMHO if you have to change/modify an external lib, create a patch from
> your changes and have that patch somewhere versioned as well. Then after
> upgrading the lib (using the vendor branch command) you can apply the
> patch again to that new version.

I'm referring to
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html, which
discusses the concept of "vendor branching" as it relates to Subversion.

It is pretty much entirely about tracking and preserving custom local
changes made to code supplied by external vendors. So this is what
people will be expecting when they see something associated with SVN
talking about vendor branching.

I'm not saying that this feature is a bad feature (in fact it's a very
useful one, in the absence of local changes), just that it has a bad
name -- it's going to make people jump to the wrong conclusions about
its functionality.

Maybe you should call it "reimport here" rather than "vendorbranch
here"? (And clarify that the containing folder needs to be dropped, not
the contents.)

(Though a GUI-interactive version of svn_load_dirs.pl would be awesome.)


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-17 01:01:37 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

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