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