On Fri, 2002-09-27 at 14:20, Ben Collins wrote:
> On Fri, Sep 27, 2002 at 12:02:52PM -0700, Kean Johnston wrote:
> > > > Have you considered storing the text-base files compressed?
> > > It would
> > > > be pretty easy to implement - you've already got zlib in there - and
> > > > save quite a bit of disk for only a small speed penalty.
> > > >
> > >
> > > I like that idea. Plus, it only affects libsvn_wc.
> >
> > Not sure sure how "small" the speed penalty would be. It takes over 11
> > minutes to compress the tarballs of the repository I am wanting to
> > subvert
> > (is that the right work for moving to subversion? :). 11 minutes is
> > quite
> > noticable.
>
> It's a one time 11minutes on checkout though. Not something that has to
> happen with every command. And by far, decompression takes far less
> time.
>
Is there some reason they don't use hardlinks?
With hardlinks, and checksum verifications you should be really safe to
have the text bases in .svn be duplicated space wise if and only if
you've changed the file. A number on the LKML people do this with tar
balls or Bit Keeper. This speeds up the diff incredibly, because the
first thing they do on the stat, is see if it is the same filesystem,
and the same inode if they are, it's the same file don't check anything
else.
Your editor must respect hardlinks, which I believe emacs does, and vim
can (but doesn't by default). Your editor must do unlink/open/write,
rather then open/write if I remember correctly.
I'd be really excited if that was an option (--hard-link) to svn co, and
svn cp file:// file:// copies. It would be a serious optimization for
me. I generally have 3-8 trees checked out, all with small individual
changes in them (I touch maybe 20 of the 5000 files in my source tree on
average). The 8 is a limitation of file space. With svn, I'd only get
4. With that kind of space savings I could get all of them for the
price of one, plus the size of the individual files I'd changed.
If for some reason if the user uses this option, and then uses an editor
that doesn't do the right thing, the checksums/timestamps in
.svn/entries should find it as corruption.
Now you have interesting issues with getting APR to do that, and
windows can't do that, so it's no good for the Window's people, but it's
a serious boon for the UNIX like FS's out there in the world. I'd
seriously consider switching to Emac's if I can't make vim do it. The
space/speed savings is more then worth it...
Sorry if I brought up an old argument... I haven't seen it since I
started following the list a while back. I've always been sort of
curious about this.
Yes for windows (9x at least), this won't work.
Thanks,
Kirby
> --
> Debian - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> Deqo - http://www.deqo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 27 22:46:49 2002