[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: Brad Cox, Ph.D. <bcox_at_virtualschool.edu>
Date: 2006-11-16 23:57:09 CET

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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Thu Nov 16 23:57:49 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.