Re: Noninvasive administrative areas (.svn)

[David Waite <ma...@akuma.org>]

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

Re: Noninvasive administrative areas (.svn)

[Ben Collins-Sussman <su...@collab.net>]

On Sun, 2003-11-30 at 19:27, David Waite wrote:
> 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.
> 

The other reason we chose the CVS model was portability... just pick up
your working copy and move it to another machine.  Or, pick up just a
subsection of your working copy... any subdirectory can survive as a
standalone working copy.  Most of the developers consider this a
feature, not a bug, so we deliberately imitated CVS.  Sorry that you
feel otherwise, Stuart.

> I imagine people will start 
> to attack the problem of allowing the working copy implementation to be 
> switched for the 1.1 timeframe

As David said, yes, in post-1.0 subversion, people will be working on
making the .svn/ directories optional, allowing them to live outside the
working tree.  It's definitely important to a small, vocal minority, and
has been brought up before.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org