You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by CARASSO Felipe <Fe...@gemalto.com> on 2007/08/24 22:39:14 UTC
Recurring problem with the SVN structure for WC
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
Re: Recurring problem with the SVN structure for WC
Posted by Talden <ta...@gmail.com>.
> Starting from there, the development should only depend on whatever
> tool the developer finds fit. Let's say that for creating a file or a folder
> the developer likes to use, say, TotalCommander.
A fine goal and of course you can create a file or folder with any tool
you like. It's just not implicitly scheduled to be added.
> Creating a file or folder likely includes copying that file or folder from
> somewhere else in the project.
> Just then, the developer should be able to decide that his project is
> in a state that requires versioning. Just then, it should call Subversion
> and ask for versioning-related operations.
> I believe that copying files and folders around in a project should not be
> considered part of Subversion's group of operations. That's why I have
> the impression that "svn copy" and "svn move" are more like
> workarounds to support what has been decided as "how Subversion
> works" rather than being part of version control tasks.
I hope I've misunderstood your intent here. One of the major benefits
for users moving from CVS is that Subversion does retain knowledge of
where files are copied/moved from in history. To achieve this
non-ambiguously Subversion must be involved in the copy/move
operation.
Of course sometimes you don't want the link to history but do want to
copy a folder tree - in this instance the WCA (Working Copy
Administration) does get in the way.
> So if I'm right, and if my proposal is feasible, I don't see why the user
> should be forced to do copy/move under a Subversion-controlled
> environment if he could use whatever tool he'd like without
> compromising the version control.
For copying, the user isn't 'forced' to do so now (though they'll lose
the history link and be required to schedule additions separately).
For the deletion part of a move (or a plain deletion), you do need to
use Subversion (and you can't remove the folders until you've
committed).
For the folder copy the WCA does get in the way and that is a pain.
This is only one of several ways in which the current approach to WCA
is inconvenient - searching/replacing across folder trees being the
other biggest offender.
Note: I would not want direct deletions of files from the working copy
to be seen as implicit scheduled deletes just as I would want to see
new files implicitly scheduled for addition. These would cause more
serious issues than the current WCA layout - once committed to the
repository everyone feels the pain of a users mistake.
The good news is that it sounds like those working on the WCA layout
issue are well aware that there are issues to deal with and are
dealing with them... As noted it isn't just a trivial relabeling of
folder locations to retain all the current Subversion capability and
move the WCA at the same time.
Erik, is there a document or thread that discusses the work that is being done?
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Recurring problem with the SVN structure for WC
Posted by CARASSO Felipe <Fe...@gemalto.com>.
> -----Original Message-----
> From: Talden [mailto:talden@gmail.com]
> Sent: Tuesday, August 28, 2007 4:00 AM
> To: Ryan Schmidt
> Cc: Matt Sickler; CARASSO Felipe; users@subversion.tigris.org
> Subject: Re: Recurring problem with the SVN structure for WC
>
> > Subversion is not a toaster. It's a complicated piece of machinery,
> > and only proper education of the users will result in its
> being used
> > correctly.
>
> Absolutely. Users still need to understand the implications
> of their actions.
Before replying, a reminder: I'm advocating for what I think that would make Subversion a better product. My thoughts come
from the need of making Subversion useful to people other than developers and system administrators. Many of these people are
qualifiers and project managers.
I find it a dangerous perspective to use "RTFM" as a default answer, specially when a product is fighting its way into
widespread acceptance.
First of all, the task of controlling the version of a project should not have more priority than other tasks that are only
related to the development of that project.
Starting from there, the development should only depend on whatever tool the developer finds fit. Let's say that for
creating a file or a folder the developer likes to use, say, TotalCommander. Creating a file or folder likely includes copying that
file or folder from somewhere else in the project.
Just then, the developer should be able to decide that his project is in a state that requires versioning. Just then, it
should call Subversion and ask for versioning-related operations.
I believe that copying files and folders around in a project should not be considered part of Subversion's group of
operations. That's why I have the impression that "svn copy" and "svn move" are more like workarounds to support what has been
decided as "how Subversion works" rather than being part of version control tasks.
So if I'm right, and if my proposal is feasible, I don't see why the user should be forced to do copy/move under a
Subversion-controlled environment if he could use whatever tool he'd like without compromising the version control.
>
> In the suggested solution, users who use an OS delete of
> folders in the working copy would implicitly have scheduled
> removals. A commit from an unaware user could be disastrous
> (of course the same disaster is currently possible by
> touching files and committing those - explicit scheduling of
> changes would avoid this).
I'm not sure, but it looks like you replied to your own statement there :) If I'm not mistaken, in the current Subversion
context, implicit changes can happen no matter how the user does changes to the project. It all depends on how you define
"implicit". For me, if the user does 100 changes and forgets about 80, those 80 become implicit.
Best regards,
Felipe
Re: Recurring problem with the SVN structure for WC
Posted by Talden <ta...@gmail.com>.
> Subversion is not a toaster. It's a complicated piece of machinery,
> and only proper education of the users will result in its being used
> correctly.
Absolutely. Users still need to understand the implications of their actions.
In the suggested solution, users who use an OS delete of folders in
the working copy would implicitly have scheduled removals. A commit
from an unaware user could be disastrous (of course the same disaster
is currently possible by touching files and committing those -
explicit scheduling of changes would avoid this).
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Recurring problem with the SVN structure for WC
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/28/07, Erik Huelsmann <eh...@gmail.com> wrote:
> On 8/28/07, CARASSO Felipe <Fe...@gemalto.com> wrote:
> >
> > Excelent news! Looks like I won't have to have my own eyes burned on that matter. Thank you!
>
> Which is something I already told you 2 days ago.
>
I sent that message too early, because what I wanted to add is that in
the same message where I told you that, I also told you it's still a
rewrite of the underlying library. You (probably) wouldn't have pulled
it off on your own, as it requires changes to some of the fundamental
lemmas on which the library is based.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Recurring problem with the SVN structure for WC
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/28/07, CARASSO Felipe <Fe...@gemalto.com> wrote:
>
> Excelent news! Looks like I won't have to have my own eyes burned on that matter. Thank you!
Which is something I already told you 2 days ago.
Bye,
Erik.
>
> Best regards,
> Felipe
>
> > -----Original Message-----
> > From: Miller, Eric [mailto:Eric.Miller@amd.com]
> > Sent: Tuesday, August 28, 2007 11:06 AM
> > To: Miller, Eric; Ryan Schmidt; Matt Sickler
> > Cc: CARASSO Felipe; users@subversion.tigris.org
> > Subject: RE: Recurring problem with the SVN structure for WC
> >
> (...)
> >
> > Just saw this on the dev list:
> >
> > > -----Original Message-----
> > > From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> > > Sent: Monday, August 27, 2007 1:43 PM
> (...)
> > >
> > > We're planning to centralize all the administrative data
> > for a WC at
> > > the top of the WC, and provide a 'svn detach' command to allow for
> > > severable sub-directories. The WC data storage format will
> > probably
> > > change drastically when we do this, likely moving into
> > something like
> > > sqlite. The information we track will likely be a superset
> > of what's
> > > tracked today in all the .svn dirs.
> >
> > So at least plans are underway to tackle this issue.
> >
> > Eric
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Recurring problem with the SVN structure for WC
Posted by CARASSO Felipe <Fe...@gemalto.com>.
Excelent news! Looks like I won't have to have my own eyes burned on that matter. Thank you!
Best regards,
Felipe
> -----Original Message-----
> From: Miller, Eric [mailto:Eric.Miller@amd.com]
> Sent: Tuesday, August 28, 2007 11:06 AM
> To: Miller, Eric; Ryan Schmidt; Matt Sickler
> Cc: CARASSO Felipe; users@subversion.tigris.org
> Subject: RE: Recurring problem with the SVN structure for WC
>
(...)
>
> Just saw this on the dev list:
>
> > -----Original Message-----
> > From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> > Sent: Monday, August 27, 2007 1:43 PM
(...)
> >
> > We're planning to centralize all the administrative data
> for a WC at
> > the top of the WC, and provide a 'svn detach' command to allow for
> > severable sub-directories. The WC data storage format will
> probably
> > change drastically when we do this, likely moving into
> something like
> > sqlite. The information we track will likely be a superset
> of what's
> > tracked today in all the .svn dirs.
>
> So at least plans are underway to tackle this issue.
>
> Eric
RE: Recurring problem with the SVN structure for WC
Posted by "Miller, Eric" <Er...@amd.com>.
> -----Original Message-----
> From: Miller, Eric
>
> Having the ability to remove the metadata from the working copy would
be
> absolutely brilliant IMO. A number of VC tools seem to get by with
> this.
Just saw this on the dev list:
> -----Original Message-----
> From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> Sent: Monday, August 27, 2007 1:43 PM
> To: Taylor Gautier
> Cc: Subversion Developers
> Subject: Re: questions regarding svn metadata (.svn)
>
>
> On Aug 26, 2007, at 12:16 PM, Charles Acknin wrote:
>
> > On 8/26/07, Taylor Gautier <tg...@terracottatech.com> wrote:
> ...
> >> * have there ever been any discussions about using a different
> >> style for
> >> storing the metadata - e.g. ala perforce - instead of .svn
files/dirs
> >> everywhere? I don't want to start a new discussion on this topic
> >> without having read any existing discourse
>
> We're planning to centralize all the administrative data for a WC at
> the top of the WC, and provide a 'svn detach' command to allow for
> severable sub-directories. The WC data storage format will probably
> change drastically when we do this, likely moving into something like
> sqlite. The information we track will likely be a superset of what's
> tracked today in all the .svn dirs.
So at least plans are underway to tackle this issue.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Recurring problem with the SVN structure for WC
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 28, 2007, at 09:32, Miller, Eric wrote:
> Ryan Schmidt wrote:
>
>> Exactly, Matt. The only reason I can think of why one would care
>> where Subversion stores its admin directories is that one is copying
>> and moving files using native OS commands instead of using svn cp and
>> svn mv. And that would be a user error. One must use svn cp and svn
>> mv. The book goes into it in some detail and there's also a relevant
>> FAQ entry:
>
> BUZZ. Incorrect assumption. You totally neglect 3rd party CLOSED
> SOURCE applications that may manipulate data however they see fit.
> The
> meta data is often a casualty.
That... is of course a good point. And you're right, I do tend to
forget that point, as I haven't been versioning such data much. But
this has bitten me on one .rtfd file I version, which gets borked
every time I change and save it in TextEdit. It is a happy side-
effect that moving the meta-data out of the individual directories
would fix part of the opaque collection issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
> Also, implicit in this discussion is just the general fragility of the
> meta-data to begin with. I can't even begin to list the number of
> hoops
> I've had to jump through to repair a working copy *without starting
> from
> scratch*. From what I've been reading 1.5 may help with some of that.
>
> Having the ability to remove the metadata from the working copy
> would be
> absolutely brilliant IMO. A number of VC tools seem to get by with
> this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Recurring problem with the SVN structure for WC
Posted by "Miller, Eric" <Er...@amd.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
>
> Exactly, Matt. The only reason I can think of why one would care
> where Subversion stores its admin directories is that one is copying
> and moving files using native OS commands instead of using svn cp and
> svn mv. And that would be a user error. One must use svn cp and svn
> mv. The book goes into it in some detail and there's also a relevant
> FAQ entry:
BUZZ. Incorrect assumption. You totally neglect 3rd party CLOSED
SOURCE applications that may manipulate data however they see fit. The
meta data is often a casualty.
Also, implicit in this discussion is just the general fragility of the
meta-data to begin with. I can't even begin to list the number of hoops
I've had to jump through to repair a working copy *without starting from
scratch*. From what I've been reading 1.5 may help with some of that.
Having the ability to remove the metadata from the working copy would be
absolutely brilliant IMO. A number of VC tools seem to get by with
this.
Just my 2c.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Recurring problem with the SVN structure for WC
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 27, 2007, at 22:06, Matt Sickler wrote:
> On 8/27/07, CARASSO Felipe wrote:
>
>>> Well, at the least, you've introduced a new error state to deal
>>> with.
>>> In the current model the content folder must exist if the
>>> administration area exists (one is a file-system descendant
>>> of the other). In the proposed approach this is not the case
>>> so you have to either treat a missing content folder as
>>> missing content to be recreated during an update, evidence of
>>> a remove, or a working copy error.
>>
>> Since the premisse is that only the versioned data was copied, and
>> not the control data (note that this is the goal of my proposal),
>> the assumption would be that when control is there and data isn't,
>> it means that a "delete" needs to be commited.
>>
>> Note also that with the current model you copy versioned data
>> *and* control data, ending up with control data that has nothing
>> to do
>> with what's in the server. This is the motivation of my proposal.
>
> I think the error lies with the users, not the tool. Perhaps you can
> better educate those users who are having problems in the proper use
> of svn.
> I am curious though, how they copy and paste stuff, and not get the
> .svn folders. Are they doing the equivalent of moving / coping things
> around without telling svn (ie, using cp and mv instead of svn cp and
> svn mv) ??
> If that is the case, it would be much more efficient to tell the users
> the correct way to do it.
> If they are using tools like TortoiseSVN, its already built in to the
> right-click menu.
Exactly, Matt. The only reason I can think of why one would care
where Subversion stores its admin directories is that one is copying
and moving files using native OS commands instead of using svn cp and
svn mv. And that would be a user error. One must use svn cp and svn
mv. The book goes into it in some detail and there's also a relevant
FAQ entry:
http://subversion.tigris.org/faq.html#wc-change-detection
Subversion is not a toaster. It's a complicated piece of machinery,
and only proper education of the users will result in its being used
correctly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: Recurring problem with the SVN structure for WC
Posted by Matt Sickler <cr...@gmail.com>.
I think the error lies with the users, not the tool. Perhaps you can
better educate those users who are having problems in the proper use
of svn.
I am curious though, how they copy and paste stuff, and not get the
.svn folders. Are they doing the equivalent of moving / coping things
around without telling svn (ie, using cp and mv instead of svn cp and
svn mv) ??
If that is the case, it would be much more efficient to tell the users
the correct way to do it.
If they are using tools like TortoiseSVN, its already built in to the
right-click menu.
On 8/27/07, CARASSO Felipe <Fe...@gemalto.com> wrote:
> Just for the sake of discussion (because I'm already convinced that if I want to see this done I'll have to do it myself), please
> bear with me:
>
> > Well, at the least, you've introduced a new error state to deal with.
> > In the current model the content folder must exist if the
> > administration area exists (one is a file-system descendant
> > of the other). In the proposed approach this is not the case
> > so you have to either treat a missing content folder as
> > missing content to be recreated during an update, evidence of
> > a remove, or a working copy error.
>
> Since the premisse is that only the versioned data was copied, and not the control data (note that this is the goal of my proposal),
> the assumption would be that when control is there and data isn't, it means that a "delete" needs to be commited.
>
> Note also that with the current model you copy versioned data *and* control data, ending up with control data that has nothing to do
> with what's in the server. This is the motivation of my proposal.
>
> >
> > To maintain the 'detachability' of the current approach you
> > also need to provide a 'detach' command to extract part of an
> > existing working copy into a new, self-contained, working copy.
>
> Would you elaborate on that? I'm unaware of "detachability" for only part of a project tree. Is that an SVN controlled state or a
> lack of control data? In the latter, I'd think it would cause files to be reported as unversioned.
>
> >
> > My point is that it is not _just_ as simple as redirecting some paths.
>
> Even so, I'm still inclined to think that it's way closer to the "just" than to the "changes everything in the library".
>
> Thank you,
> Felipe
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Recurring problem with the SVN structure for WC
Posted by CARASSO Felipe <Fe...@gemalto.com>.
Just for the sake of discussion (because I'm already convinced that if I want to see this done I'll have to do it myself), please
bear with me:
> Well, at the least, you've introduced a new error state to deal with.
> In the current model the content folder must exist if the
> administration area exists (one is a file-system descendant
> of the other). In the proposed approach this is not the case
> so you have to either treat a missing content folder as
> missing content to be recreated during an update, evidence of
> a remove, or a working copy error.
Since the premisse is that only the versioned data was copied, and not the control data (note that this is the goal of my proposal),
the assumption would be that when control is there and data isn't, it means that a "delete" needs to be commited.
Note also that with the current model you copy versioned data *and* control data, ending up with control data that has nothing to do
with what's in the server. This is the motivation of my proposal.
>
> To maintain the 'detachability' of the current approach you
> also need to provide a 'detach' command to extract part of an
> existing working copy into a new, self-contained, working copy.
Would you elaborate on that? I'm unaware of "detachability" for only part of a project tree. Is that an SVN controlled state or a
lack of control data? In the latter, I'd think it would cause files to be reported as unversioned.
>
> My point is that it is not _just_ as simple as redirecting some paths.
Even so, I'm still inclined to think that it's way closer to the "just" than to the "changes everything in the library".
Thank you,
Felipe
Re: Recurring problem with the SVN structure for WC
Posted by Talden <ta...@gmail.com>.
> 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?
Well, at the least, you've introduced a new error state to deal with.
In the current model the content folder must exist if the
administration area exists (one is a file-system descendant of the
other). In the proposed approach this is not the case so you have to
either treat a missing content folder as missing content to be
recreated during an update, evidence of a remove, or a working copy
error.
To maintain the 'detachability' of the current approach you also need
to provide a 'detach' command to extract part of an existing working
copy into a new, self-contained, working copy.
My point is that it is not _just_ as simple as redirecting some paths.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Recurring problem with the SVN structure for WC
Posted by Lira Olavo <Ol...@gemalto.com>.
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 <ta...@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 <Fe...@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
Re: Recurring problem with the SVN structure for WC
Posted by Talden <ta...@gmail.com>.
> > 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!
My point was that providing the detachability in this manner was the
result of observing how CVS provided it - yet as many point out,
providing a detach command would provide the capability whilst
unencumbering the working copy from this distributed administration.
> 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?
My response was pointing out that the effort is larger than merely
relabeling some paths in the working copy code - specifically for the
edge-cases you note (and others).
> > 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.
Agreed. In fact I think the effort is probably wasted to try and
massage the existing code to make this small improvement. It's a more
complicated change than the benefits warrant.
> 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.
I'm surprised people are looking at this change (simply moving
existing administration into a parallel tree) as worth the effort by
itself.
> Given the number of unfotunate choices we made as the library
> developed...
Heh, hindsight and all...
>... I doubt anybody would rewrite it in such a way that it
> wuold solve the major issues. But, yes, help is always welcome.
I'm yet to get up to speed with the source-structure and it's been a
decade since I looked at C with any serious intent - we shall have to
see.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Recurring problem with the SVN structure for WC
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi!
On 8/25/07, Talden <ta...@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 <Fe...@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
Re: Recurring problem with the SVN structure for WC
Posted by Talden <ta...@gmail.com>.
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 <Fe...@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