On Thu, Nov 10, 2011 at 4:40 PM, C. Michael Pilato <cmpilato_at_collab.net> 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.
Besides the point of default behavior, I also feel that coupling
"exclude-from-commit" to "pinning to a revision" would be mixing two
things that are not exactly the same.
Sure, if an external is pinned to a revision you can say that it must
be excluded from commit. But the reverse? That you can only exclude an
external from commit by pinning it to a revision? That would actually
make it impossible to set up "hold-on-commit" behavior for externals
like with the "svn:hold" property, another feature that you've been
working on. IIRC, the desired behavior that came out of that
discussion was that an "svn:hold" file should be updated on "svn
update", but should be filtered out from commits.
Suppose a file is not on-hold in its original location, but you want
to give it on-hold behavior in the project where you pull in the file
as an external ...
Ok, it may be a rare use case, but it's not an unreasonable one I
think. So I'm all for enriching the format of external definitions to
make "include-in-commit" an explicit option.
Received on 2011-11-11 00:41:50 CET