Hi,
Is there a way to vote for features to be implemented? The
feature proposed by Mr. Carasso is certainly one of the things my
company wishes for (along with including the lock information in the
meta-data, so the clients can display icons of locked files).
From my point of view as a CMO/QAO, one of the most difficult
things to explain for the users is the copy and paste from one place to
another, only 30% of ours SVN users (developers) really understand what
has to be done, others (qualifiers, integrators, project managers)
always ask for support after his WC is all messed up. This feature would
for sure make SVN more user friendly!
I don't know if Mr. Carasso will implement it or not but if he
does I'm very interested in see clients like Subversive and tortoise
using this new version of meta-data in WC in their client libraries like
SVNkit or JavaHL.
PS: Is it so difficult to just change place of the .svn to be in a
separated structure? I still have difficulty to see the "edge cases"
like: <<what should happen if an update changes a directory to a file,
yet the directory contains local changes?>> Can't it do the same
procedure as today?
Thank you!
Olavo Lira
-----Original Message-----
From: Erik Huelsmann [mailto:ehuels@gmail.com]
Sent: Sunday, August 26, 2007 1:32 PM
To: Talden
Cc: CARASSO Felipe; users@subversion.tigris.org
Subject: Re: Recurring problem with the SVN structure for WC
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 28 03:22:16 2007