On 11/10/2011 11:15 AM, Neels J Hofmeyr wrote:
> 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?
As a community, we need to decide how we will handle file externals in
general. Their clever implementation invites inconsistency.
I prefer that file externals be treated the same way as directory externals
in every behavior possible. I find that easier to understand and account
for myself, easier to explain to others. But I don't know that the rest of
the devs think the same way about them that I do.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-11-10 19:10:54 CET