Re: Recurring problem with the SVN structure for WC

This issue is old news I'm afraid.

I expect the primary reason that Subversion working copies store a
meta-data folder within each versioned folder is that CVS did it that
way. The only real redeeming feature of this approach is that each
working copy folder is itself a self functioning working-copy.

Changing the working-copy is much larger and more fundamental than
merely traversing two parallel trees - keeping these trees
synchronised and dealing with synchronisation issues are not going to
be simply changing a few paths in the code. The working copy also
increases in complexity with an additional folder per versioned
folder.

On the other hand, I believe it will prove to be critical to
Subversions continuing popularity to update it's working copy model -
for a number of reasons that I think are more important than the
convenience of not scattering meta-data folders throughout the working
copy.

Given the efforts required to design, implement and test a new working
copy (and the impact on every tool and script that supports Subversion
with expectations of the existing working-copy model) I doubt that
making such an expensive change for such a small benefit will be
encouraged or actioned by the existing committer community (though I
certainly don't speak for them).

Of course you can always grab the source and work on the change
yourself and, though unlikely, if your approach proves popular it
might be accepted into the official project - A better and probably
more successful approach might be to get a more complete submissions
and review process under-way to design a working-copy model that
addresses a more ambitious set of the perceived short-comings of the
current approach - I'm certain you will get no shortage of
suggestions, some of which are probably in the issue tracker, most of
which are definitely in the archives of this mailing list (or the dev
list).

Consider looking at SVK which has a much more ambitiously different
approach to the working copy model - it has proven quite popular.

--
Talden
On 8/25/07, CARASSO Felipe <Felipe.CARASSO@gemalto.com> wrote:
> Greetings everyone,
>
>         There's a recurrent problem when trying to put Subversion into use by an heterogeneous team containing developers, project
> managers and so on. This problem is the fragility of the Subversion control files, namely ".svn" folders and contents.
>
>         It's kind of difficult to enforce the idea of not copying folders out of a Subversion-safe environment due to the mess that
> the hidden folders create.
>
>         I confess that I ignore the reason why CVS and SVN insist in keeping control files for each folder inside the respective
> folder. I suspect that it has something to do with having multiple small files instead of one huge file, or maybe speeding up the
> search for the file's version properties.
>
>         If that's so, I suggest a structure like this:
>
> ProjectRoot
> ..|
> ..+- .svntree/
> ..|....+- .svn/ (for ProjectRoot)
> ..|....|....+- svndir1/ (I.e. prop-base for ProjectRoot)
> ..|....|....+- svndir2/ (I.e. props for ProjectRoot)
> ..|....|....+- .../
> ..|....|....+- entries (for ProjectRoot)
> ..|....|....+- ...
> ..|....|
> ..|....+- ProjectDir1
> ..|....|....+- .svn/ (for ProjectDir1)
> ..|....|....|....+- svndir1/ (I.e. prop-base for ProjectDir1)
> ..|....|....|....+- svndir2/ (I.e. props for ProjectDir1)
> ..|....|....|....+- .../
> ..|....|....|....+- entries (for ProjectDir1)
> ..|....|....|....+- ...
> ..|....|....|
> ..|....|....+- .../
> ..|....|
> ..|....+- ...
> ..|
> ..+- ProjectDir1
> ..|....+- .../
> ..|....+- ...
> ..|
> ..+- .../
> ..+- ...
>
>         In other words, separate the tree of SVN control files from the real files and put it in the project root.
>
>         The advantage of that is that copying folders around won't mess the versioning information. Except, of course, copying the
> project root to another project. But in that case, the Subversion client could ignore ".svntree" in a subfolder which the parent
> already had an ".svntree".
>
>         In such situations, copying from one place to another would have the expected result, which is, having unversioned folders
> and files in the destination. And that would happen no matter which interface the user would have used.
>
>         The Subversion client would only need to navigate through two parallel trees instead of a single one. I believe that it
> would have little if any impact on performance or resources.
>
> Thank you for your attention,
>
> Felipe Carasso
> Developer
> Latin America Card Development Group - SIM Applications client/server Gemalto
> Tel: + 1-514-732-2342
> Fax: + 1-514-732-2301
> 3 Place du Commerce, bureau 300
> Montreal, Quebec, Canada, H3E 1H7
> felipe.carasso@gemalto.com
> www.gemalto.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org