The reason CVS and Subversion both have per-directory working copy
administrative areas is that it is the best way known to track changes
made with filesystem commands like mv and rm. Most straw-man 'central
repository' ideas do not cope well or at all with multiple users
working against a single working copy, moving the working copy to a
different location, copying a working copy whole, or removing a working
copy.
That said, there are other reasons to not want the administrative areas
inserted into the working copy - I might want to just revision control
a single file, or have "opaque collections" for supporting tools which
treat certain directory structures as if they were files, and thus do
not handle the traditional semantics well. I imagine people will start
to attack the problem of allowing the working copy implementation to be
switched for the 1.1 timeframe (I know I'm working on a proposal for
making the working copy code a pluggable provider interface right now).
However, I doubt that anything other than the CVS model will become the
default standard on platforms without filesystem functionality for
solving these problems (i.e. being able to attach the working copy
information onto custom metadata of the files and directories), just
because they all impose additional restrictions that additional
filesystem operations have to be performed with the subversion tools
and not the normal shell/command-line/finder/explorer mechanisms.
-David Waite
On Nov 30, 2003, at 2:41 PM, Stuart Clayton wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 1 02:28:07 2003