Hi,
I nearly fell out of my pants when I read about the Subversion project on
the apache site. An alternative to CVS!!! I thought, they've surely
corrected that one big CVS annoyance, namely that administrative areas
(.cvs) are bang in the same physical directory structure as the working
copies, as "parallel directories".
CVS administration areas are parasitical on working copy URLs for absolutely
no good reason. You can't even zip a source structure without shlepping the
.cvs directories along as well. Also, in the Java world, these .cvs
directories show up in IDEs such as WSAD and eclipse, clogging the source
views.
It is a general design principle that internal processing artefacts of a
program (such as CVS) should not be hardwired to what the program processes
(working copies). The "link" between them (how the program artefacts find
what has is to be processed) is provided by configuration- things like
libpaths, classpaths, build tool settings or a TEMP environment variable. A
C IDE doesn't insist on copying standard libraries into my C source
directories, nor does java.exe require me to copy the jre tree into my start
directory.
But it looks like I'm too late- the Subversion administrative areas .svn are
in the same physical directory structure as the working copies, only as a
subdirectory instead of a parallel directory, if I've seen aright.
On the other hand, if the Subversion code is properly modularized, it should
be a snip to provide for specification of an URL prefix for an
"administrative area root" that is different from the working copy root...
The structures could "mirror" each other as they do now, but by *mapped* URL
prefixes (administrative root to working copy root) instead of requiring the
prefixes to be identical.
Regards,
Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 1 01:44:09 2003