[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: Tim Hill <drtimhill_at_comcast.net>
Date: 2006-11-17 01:05:23 CET

There's no perf hit ... all you are doing is walking up the folder
tree. Say you are 20 levels deep (!!), that's just 20 folders to scan
for a .svn folder. We're talking milliseconds here, even over a
network, and most working copies are on local HDD.

Tools like perforce and SD have been using this model for years.

--Tim

On Nov 16, 2006, at 2:57 PM, Brad Cox, Ph.D. wrote:

> Surely such bright fellows could find a bulletproof alternative?
> Like instead of open("./.svn"), open($DIR), where $DIR is redefined
> in each subdir as ../../..(however many)/root.svn. It'd might
> tricky getting all the corner cases, but it just doesn't seem that
> hard.
>
> Ryan Schmidt wrote:
>> 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
>
> <bcox.vcf>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 01:06:01 2006

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