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

Why .svn directory? (was: Mac OS X "packages" Best Practices?)

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-03-03 13:55:26 CET

On 3/2/2006 5:45 PM, Richard Jolly wrote:
> On 2 Mar 2006, at 18:51, Russ Brown wrote:
>> I've come to this thread a little late but I do have an alternative
>> solution: use SVK as your client instead of svn. SVK uses a different
>> working copy format that doesn't involve adding .svn directories to
>> each
>> and every directory in the working copy. In fact it doesn't add
>> anything
>> to the working copy: the working copy information is stored elsewhere.
> ... in ~/.svk
> Which has the nice effect that all the other unix tools don't
> constantly bump into the .svn dirs. I'm curious why doesn't subversion
> itself take this approach?

I'm also curious, and have changed the subject line to hopefully attract
more answers.

I think there are some overly simple answers:

1. Because CVS did it that way, and SVN is a descendant.

2. Because SVN stores a duplicate of each working copy, and it's nice
to get rid of both the WC and it's duplicate with a simple rm -rf.

3. Because the user who checked out the working copy may not be the
only one to access it; it would be hard to synchronize multiple ~/.svn
files without some sort of info stored in the working copy to point to them.

But I suspect there are better answers...

I also really like the idea of keeping a duplicate of the repository on
disk as a reference the way SVK does, instead of just a duplicate of the
working copy as SVN does. I often have two or three branches of my
project checked out, so I suspect the total disk space would be
comparable, but I'd have the advantage of being able to look through the
history even when offline.

Duncan Murdoch

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 3 13:58:46 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.