[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: .svn directories (no doubt) revisited

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-11-16 21:22:18 CET

On Nov 16, 2006, at 13:36, Talden wrote:

> On 17/11/06, Tim Hill wrote:
>
>> imho, the svn team would have better with a single .svn folder tree
>> off the root of the working copy, so that there were two independent
>> but related trees. This would have avoided any number of problems
>> with today's implementation.
>
> At face value this seemed a reasonable option... Let's say it
> worked as
>
> svn co .../dev/projA/trunk a_trunk
>
> and this produced
>
> a_trunk/
> svn/
> ...
> wc/
> src/
> something/
>
> This sounds good initially but fairly clearly introduces a fairly
> significant condition. the .svn handling for folder 'something' needs
> to know that, rather than ./.svn/ it must look for svndata in
> ../../../svn/... (or whatever the locative ends up being).

Right. And that would seem to be a performance hit for using a
working copy. Instead of Subversion looking in one known place
(the .svn directory in the current directory), it has to look in
potentially all parent directories to discover whether the thing even
is a working copy.

> imagine how easy converting the working copy to an export would be.

True: currently, an export is a bit of work for the system, searching
the entire directory tree for the .svn directories. But making an
export is, I think, in general, an infrequent operation, while using
a working copy is a frequent operation. I'd prefer that frequent
operations be fast, at the expense of infrequent operations being
slow, not vice-versa.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 21:23:24 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.