Neels J Hofmeyr wrote: > I think there is general agreement (to the degree of common > sense?) that file and dir externals should behave the same > way.
+1 to that. > I would be fine with keeping current trunk: it changes file > externals' default behavior, so that they are treated like > dir externals. So now it's: never include any externals in > commit recursion, unless --include-externals. So far so good; this is definitely an improvement over the previous mixture. > But I think we still do need to add a way of making an > external get included by default. Now we're getting into the subject of people using externals for different purposes. Sometimes as a "view spec" to connect other subtrees of their own repository into the WC to make (as seamlessly as possible) a single WC so that they can edit and commit it all together. Sometimes as a way to place a copy of some "third-party" source code into their working copy, but in a read-only manner in terms of version control: they don't intend to commit to it. > It was suggested to extend the svn:externals syntax, adding > a flag that marks externals that should behave differently. > By now this seems to me to be the best way out. What would > that look like? [suggestion snipped] The real-world issue is that there are different uses for externals, and one set of behaviour is not appropriate for all uses. In particular, there's a "read-only" usage and a "part of my working copy editing space" usage. Maybe we should not jump straight from the real-world issue to a switch that's designed to control just one aspect of Subversion's behaviour. That might not really be a solution to the problem. I don't want to see us extending the "externals" feature with a new little knob every year, and then telling users that they can certainly get the result they need, all they have to do is remember to set the magic incantation "x=N y=0 z=yes" every time. It's hard work for us to think and define two or three categories of real-world uses that will best fit the ways people want externals to behave, but if we do that we will be providing users with a useful machine and not just a collection of parts. If a user doesn't want "commit" to recurse into their checkout of some third-party source code, then they probably don't want "svn propset -R" or "svn revert -R" to recurse into it either. In fact they might even like the files in that sub-tree to be marked read-only on disk. What I'm saying is there's a set of specific behaviours that all come together as a collective way to treat "a subtree of third-party files". Each individual aspect of that behaviour, such as whether to make the files read-only on disk, should be designed by us as part of a coherent whole behaviour. (If that setting needs to be user-controllable, then it should probably be in e.g. the per-user config, not a switch in the "external" definition.) So what's my suggestion? * Two new modes, each signified by some switch in the external definition. * "read-only third-party" mode -- Exclude this external from recursive commit, propset, add, delete, revert, etc. Maybe also warn if targets in this external are specified in such commands along with targets in the parent working copy, because such specifications are likely to be accidental. As a future enhancement, maybe make the checked-out files read-only on disk a bit like svn:needs-lock does. * "full participation working-copy" mode -- Include in recursive commits and modification commands (propset, add, revert, etc.). * If neither mode is specified in the external definition, use the default behaviour which is the current trunk behaviour, perhaps with further changes if we decide to make the default better or more self-consistent at the expecnse of backward compatibility. The principle is that the user should choose the general mode, and then any specific enhancements to the way Subversion handles that mode should be obtained just by updating the client software and not by requiring the user to add more switches into the external definitions. In other words, I think users will appreciate us giving them just a simple mode selector described in high-level task-focused (not vague) terms, and thinking centrally (here in the dev community) about exactly what aspects of Subversion's behaviour will best work together to facilitate those tasks. - Julian
