Hi!
On 8/25/07, Talden <talden@gmail.com> wrote:
> This issue is old news I'm afraid.
Yes. As old as Subversion itself, unfortunately.
> 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.
Apart from CVS doing it that way, back in the day when the librarie
grew up, this was considered a prime feature!
> 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.
I'm not eactly sure if I understand you correctly, but I think the
current design of the lib is as straight foward as it's going to get.
What's really problematic is all the edge cases you'll be dealing
with: what should happen if an update changes a directory to a file,
yet the directory contains local changes?
> 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.
The committers see these problems too. However, the current state of
the code does not really allow anything other than small additions of
features. A rewrite of the code is required to achieve anything major.
> 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).
I am one of them and have talked to several others who would like to
start working on exactly this change. The current focus is
merge-tracking, though.
> 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).
Given the number of unfotunate choices we made as the library
developed, I doubt anybody would rewrite it in such a way that it
wuold solve the major issues. But, yes, help is always welcome.
bye,
Erik.
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 26 19:29:15 2007