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

Re: AW: [PATCH] commit --include-externals (v2)

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Thu, 10 Nov 2011 17:15:12 +0100

On 11/10/2011 04:40 PM, C. Michael Pilato wrote:
> On 11/10/2011 10:29 AM, Neels J Hofmeyr wrote:
>> It seems to me that excluding only those externals (dir& file) that are
>> fixed to a specific revision is the best solution. My only worry are all
>> those users out there expecting dir externals to be excluded always.
>>
>> That's why I'm asking: if I told everyone to place a specific revision in
>> their externals definitions to be able to exclude them from commits, would
>> that cause major havoc?
>
> Major havoc? Perhaps not so much. But realize that we'd be telling folks
> to make a versioned change to *their data* solely for the purpose of
> preserving a behavior they have grown to expect already. We're not asking
> them to tweak local configuration, or some process point -- we're asking
> them to change their repository contents. That starts to feel (to me, at
> least) like we've crossed a line we shouldn't cross.

Where does this argument come in with file externals? Current trunk changes
the default behavior compared to 1.7.x, so that file externals are no longer
committed along by default. Would you want to revert that change?

"Fixing" externals is a dilemma at this juncture. In the end, we should have
a sane default with all the ways available to configure otherwise;
unfortunately this *will* force users to adjust, either way.

We can also: never include externals by default (current trunk), with new
svn:externals syntax to flag certain externals to be included in commit
recursion (stsp's suggestion). That, too, would allow 1.7.x behavior.

Maybe a little survey on users@ could help ... or maybe that would confuse
us for good ;)

~Neels
Received on 2011-11-10 17:15:49 CET

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.