On 11/04/2011 01:29 PM, Bert Huijben wrote:
>> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> +0 on including the support to allow the commits. (I haven't reviewed the patch in detail yet, but the idea is good)
>
> -0 to -0.5 on making it configurable as default behavior.
>
> As project we try not to add many configuration options that change the default behavior of our client.
>
> Making this configurable changes the behavior of scripts calling svn and makes it harder to test subversion by increasing the number of test scenarios.
Hmm, I see. And what if we plaster the docs for that configuration option
with something like "Warning! If you enable this, you are changing the
default behavior of Subversion, and this might break support by third-party
tools using Subversion, if any." ... ?
Not having the option of choosing a default, I'm rethinking which behavior
should be the default. I think both are valid use cases:
UC1) Prevent accidental commits to stuff coming from different areas, so
exclude externals (quite similar to the 'hold' feature). This is the use
case that would be the default with the currently proposed patch.
UC2) Patch together working copies, reusing certain parts (like common libs)
in several places, with project management needing the ability for single
commits across all externals: --include-externals.
Aha: Note that UC1 can be obtained by setting a fixed revision on externals.
As soon as they are revision-pegged, they are never included in commit
recursion (but can still be committed by passing as explicit target). UC1
can also be obtained by setting up a separate repos for untouchable stuff
(for dir externals only), as externals from another repos are currently also
never committed along. <--- answer to Mark's question
So, yeah, maybe we should make UC2 the default and provide an
--exclude-externals option. Anyone who's asking how to get a default of not
committing dir externals along can simply be told: revision peg them.
How does that sound? The changes to the patch would be trivial.
(In the meantime, the patch has seen some good review by Julian, replying in
another mail.)
~Neels
Received on 2011-11-05 00:48:48 CET