On Sat, Nov 05, 2011 at 12:48:09AM +0100, Neels J Hofmeyr wrote:
> 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.
I don't think changing the current default behaviour is a good idea.
Changing the default behaviour is more likely to break existing
scripts than a new configuration option.
As far as I understand the concern about having a configuration option
in ~/.subversion/config is that scripts might behave differently depending
on the settings in this configuration file.
I don't agree that having the configuration knob for --include-externals
is a problem. Sure, it's yet another knob to worry about. But the
consequences of misuse are relatively minor.
If a script wants to make sure it isn't affected by such settings it
should use --config-dir to use a known set of configuration files.
We cannot always make everyone happy. I would favour interactive
usability of 'svn' in your use case 2 over scriptability.
We offer bindings for scripting, which give full control over configuration
knobs to scripts.
But maybe there's a better way of handling this.
Instead of adding a new option into the configuration file, can't we
extend the svn:externals syntax to optionally specify whether an external
should be committed along with its parent by default?
Also, please do not get too side-tracked because of the discussion about
having a permanent configuration option. It is a logical next step to
follow up on your current patch. But it does in no way affect the quality
and usefulness of your current patch. So let's get that in first, and worry
about more tweaks and knobs later.
Received on 2011-11-05 10:42:53 CET