Bruce's comments are well taken, though I don't necessarily agree. As I
said, I think we should not carry forward a legacy interface for the sake of
a legacy interface. The User Ain't That Stupid(tm).
On one matter I wanted to be clearer, because I think it's important enough
to spend a few cycles on.
> > 2. Options that change semantics. Examples: the defaults for whatever
> > replaces the CVSIGNORE variable. These introduce changes in behavior
across
> > users. If buried in a config file, they can sometimes impact whether you
and
> > I can get the same output from the same command. (In the particular case
of
> > CVSIGNORE we got bit by this regularly until we learned to stop using
it).
> Nearly all the options should be specifiable from RC files and
> environment variables.
For cosmetic options that is just fine. For options that change the
semantics of what is performed I would say that they should NEVER be
specifiable from environment variables or RC files. I can live with command
line specification, but I think the user should always be aware that they
are doing something with funny consequences. Perhaps the distinction I am
trying to make will be made clearer by describing in more detail what
happened to us with the CVSIGNORE environment variable.
Early in the EROS project, I set up some automatic dependency generation
stuff in the makefiles. These generated files whose names were "*.m" and
"DEPEND". Naturally, I stuck these in my CVSIGNORE variable and forgot all
about them, except to copy them from one .cshrc to another as I upgraded
machines.
Nearly three years later some students started checking things out. One of
the first things that happened was they said to me: "Why is cvs complaining
about all of these '.m' files, and what do I do about it? One went so far as
to do a CVS add on the damn things, and then I had to go clean up after my
mistake.
Eventually, I had visions of hundreds of EROS users (okay, I'm an optimist
:-) complaining about the stupid .m files. I solved the problem by removing
my own CVSIGNORE variable and forcing myself to add the line by hand to a
.cvsignore file in every single directory.
Now there are four points to all this:
1. It was an option about the project, not about my workspace, and its
specification should have been captured in the project state rather than in
my environment. Having the ability to ignore files was a great thing, but it
had absolutely no business being in either my environment or my .cvsrc file.
2. Because it was possible to specify it in the wrong places, I took the
easy way out and got bit on the ass.
3. Given that there exists no *proper* usage of an environment variable or
.cvsrc option for this particular purpose, it shouldn't be supported from
either place.
4. [Minor addendum] It also shouldn't have been in required in *all* the
.cvsignore files. You certainly need to be able to specify such things on a
file by file or directory by directory basis, and .cvsignore files work fine
for this, but there should also have been a way to specify this globally on
a per-project basis, and in such a way that *anyone* who checked out the
project would be subject to the same rules. In CVS, this could have been
done by creating CVS/Options files (just a thought balloon -- not a
proposal).
While I'm thinking about it, the .cvsrc replacement should allow me to
specify things on a per-project basis. That's easy, and I'll gladly
volunteer to add support after SVN 0.0.1. I can live with a file that
permits me to do it wrong by specifying non-cosmetic things globally, but I
would appreciate a format that allows me to do it selectively.
Actually, in CVS the only *other* example of such an option that I can think
about is the required locking feature. Everything else really does seem to
be a cosmetic option.
Jonathan
Received on Sat Oct 21 14:36:11 2006