On Thu, Nov 10, 2011 at 4:40 PM, C. Michael Pilato <cmpil...@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. -- Johan
