On Sep 24, 2008, at 9:44 AM, Ben Webb wrote:
> Daniel Russel wrote: >> I guess the other reason was to avoid conflicts with the SConscript >> files. But since things can be checked in directly, that shouldn't be >> a problem any more (and if the files aren't listed on separate lines >> in the SConscripts, they soon will be, further making conflicts less >> likely :-) > > In a general sense, SVN write access should not be interpreted as an > invitation to go in and change everything that you don't like. If you > don't like an aspect of my policy, you can bring it up for discussion. > And if a policy isn't well defined, we can define it.
You really don't like to give up control :-) Anyway, the policies aren't yours, they are ours. And, as far as I can tell, it isn't a policy (i.e. it isn't documented as such or wasn't last I looked), it is just the way things happen to be.
As for that particular change the current setup is hard to read, hard to maintain (since you have to either insert things out of alphabetical order or reflow the names), causes SVN conflicts for no reason (since SVN doesn't know when white space is important), hard to automate (it is a bit silly that there is no script to auto generate those files since that would have avoided a number of bugs over the past year) etc... And I have brought it up before in the form of complaints about the files resulting in unnecessary conflicts, replacement files submitted from time to time and scripts to auto generate the files and never was given any reason for the current setup.
As a result, the change does not change any stated policy, has good reasons, and makes some things easier. Seems like exactly the sort of thing that opening up svn is designed to facilitate.