> The same type of solution applies to this case.
>
> I.e.,
>
> ./configure --with-version-control-system-admin-subdir=fish
>
> You get the idea. :-)
This is very very bad. What's happening is that the advocates of arbitrary
flexibility are creating conditions under which customer support for half a
dozen other things just became a LOT more complicated.
Sometimes it is better to make choices and not offer options.
In considering the same question for DCMS, I came to a different outcome
that may or may not be usable in the SVN design. I have never really loved
the CVS subdirs all over everything, and I ended up concluding that you
don't need per-directory subdirs for the CM system. I decided that it was
sufficient to have a single directory at the top of the tree that contains
all of the CM system information. If this can be done, things actually get
more efficient in terms of storage and atomicity and it becomes more
straightforward to implement commands that apply to the whole subsystem.
Also, it becomes possible to more easily layer multiple projects into the
same working source tree.
What I have tentatively done in DCMS is have a single CM system directory at
the top of the working tree. Within that directory there is a file
describing each package/project that has been checked out into the working
tree. This file is a list of the form:
true-name fs-name metadata...
(it also has a header identifying the project, branch, and version checked
out).
I should add that I'm not entirely convinced that this idea is going to work
out, but I thought I'ld put it on the table in case it was useful.
shap
Received on Sat Oct 21 14:36:06 2006