Daniel Russel wrote:
> On Sep 24, 2008, at 9:44 AM, Ben Webb wrote:
>> 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.
I think you missed my point, which was that (in general) I am wary of
blanket statements along the lines of "once I get write access I am
going to change everything" which seemed to be what you were saying.
That is precisely what others are worried about.
> 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.
I was speaking generally, but on this issue specifically it doesn't make
a lot of difference to me whether you do the current:
files = ['a', 'b', 'c', 'd']
or the proposed:
files = []
files.append('a')
files.append('b')
files.append('c')
files.append('d')
Actually, in contrast the latter is less efficient Python and looks
uglier to me (but the latter is just aesthetic of course). If you really
want each file on a separate line, I suggest:
files = [
'a',
'b',
'c',
'd',
]
At least that way the Python code is functionally the same as the
original, is still easy to auto-generate, and isn't as unnecessarily
verbose.
The only bugs I can think of were header files not being installed. That
is no longer an issue because they are staged to the build directory
now, so the compile (not just the install) will fail if a file is missed.
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle