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

Re: Compressed text-base patch

From: Eric Dorland <eric.dorland_at_mail.mcgill.ca>
Date: 2003-04-28 03:49:20 CEST

* junkio@cox.net (junkio@cox.net) wrote:
> >>>>> "ED" == Eric Dorland <eric.dorland@mail.mcgill.ca> writes:
>
> ED> After a few weeks of work on and off, here's my first stab at a
> ED> compressed text-base patch.
>
> Out of curiosity, what motivates you to compress text-base in
> the first place? Is it to save disk space for the working copy?

Yes, this is exactly the motivation.
 
> Since compressed text-base would make it slower to run working
> copy operations like "svn diff", this approach would rely on an
> assumption that most of the time, most of the files checked out
> into the working copy are not modified, especially in a large
> project where it matters. And I think it is a valid assumption.

As do I.

> If that assumption holds, however, I wonder if it would be
> simpler just to make checked-out files read-only by default, and
> make text-base hardlinks to them. This would further save the
> client side diskspace. Perhaps you can add a new command "svn
> edit" that breaks the hardlink and make the working copy file
> writable.

Yes well i think this is somewhat inconvenient. I prefer this solution
since it is perfectly transparent to the user. Your's would save more
disk space, but be much more intrusive to people's habits and work
flow.

-- 
Eric Dorland <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
------END GEEK CODE BLOCK------

  • application/pgp-signature attachment: stored
Received on Mon Apr 28 03:50:05 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.