On Fri, Jun 13, 2008 at 11:13 AM, Enrico Weigelt <weigelt_at_metux.de> wrote:
> * Andy Levy <andy.levy_at_gmail.com> wrote:
>
>> You can only switch via a dump/load cycle (make sure when you run
>> svnadmin create for the new one you specify --fs-type=bdb).
>> http://subversion.tigris.org/faq.html#dumpload
>
> Okay, my repository is "just" about 120MB big yet, so I'll
> have a try within next days.
>
> BTW: what about compression ?
>
> BTW#2: is there any way of saving space in the working copy,
> eg. by kicking off seldomly used files in the back-copy ?
> These files could be fetched on-demand (eg. on svn diff, etc).
>
> The point is: I normally check out the whole tree, including
> all tags (for convenience), but almost never change eg. tags.
>
> A really cool thing would be having an svn filesystem, which
> only presents what you're interested in (maybe the revisions
> could also appear as subdirs, like in fossil) and really does
> everything on-demand. It probably even would not need to have
> double-copies of each file, since it directly sees the change
> from the user.
>
A while back someone wrote a user space filesystem for Linux that does
this. It was written so that he could manage his photo collection in
SVN and not have a double space penalty on the working copy. I went
looking for it and could not find it - I tried Google and the SVN
Archives.
It would manage all text-base versions using hard links until you
tried to save a change to the original file, then it created a copy.
Unfortunately, it's specific to Linux.
It could also be built into Subversion such you need to 'svn edit' or
'svn open' a file for editing (ala Perforce). Somewhat similar to
locks. The problem is that I can't see how this can be easily
implemented and still work well offline (e.g. without access to the
repository and pristine copies). You'll need a (guaranteed) pristine
copy. If you keep it in another directory, you'd have to use OS
specific features (links) to have a copy 'appear' in the working
directory. If you depend in the working copy being pristine using
read-only settings, you can not be sure the user has not circumvented
this -- you could check using a hash, but unless you saved a lot
parity data, would could not re-construct a damaged file. Perhaps the
hash check is enough. If the user does subvert the process and
manually change permission and then the file, then the working copy
could just be flagged as corrupt.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-14 19:44:06 CEST