At 07:55 03.03.2006 -0500, Duncan Murdoch wrote:
>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.
I have a use case where it would be pretty usefull if the .svn were not besides
the handled files. We have a tool that saves data in different files in different
folders, it's a whole tree of data, new folders get added, others deleted. But
momentarily there's no possibility to sync these changes with a repository,
especially the deleted items. svn del file just won't work if the file is not
present anymore. And that's provided you still know what files got deleted.
I would like the svn data in a separate folder with the same tree structure
as the handled data, preferably right next to this data. So if a folder gets
deleted the svn data is still available and can be used to e.g. delete this
data also from the repository.
e.g.
BaseFolder/
File1
File2
DataFolder/
File3
File4
SubData/
File5
.svn
.svn
(existing info about File1, File2 and DataFolder)
DataFolder/
.svn
SubData/
.svn
Then I could do:
echo "new data" >> BaseFolder/File1
rm -f BaseFolder/DataFolder/SubData
mkdir BaseFolder/Data2
echo "works" > BaseFolder/Data2/NewFile
svn sync BaseFolder -m "Newest Changes"
D DataFolder/SubData/File5
D DataFolder/SubData
A BaseFolder/Data2
A BaseFolder/Data2/NewFile
M BaseFolder/File1
Would that be something for others as well? The .svn and corresponding
files would still be in one place and can be copied around or just rm'd all
at once.
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 7 11:16:32 2006