What about a compressed text-base? I've been toying with this idea and
I don't think it would be too hard to add to the existing code
base. And it would certainly go a long way to reducing the size of
those files and silencing the complainers (me being one of them :)
* Ben Collins-Sussman (sussman@collab.net) wrote:
> florin@iucha.net (Florin Iucha) writes:
>
> > 0. (Might exist already) Store in the .svn admin area checksums of the
> > base copies.
> >
> > 1. Tweak libsvn_wc/diff.c:file_diff to fetch a pristine copy from the
> > server if a cached base version is not available. The downloaded
> > pristine copy should be cached.
> >
> > 2. Add a "--no-base-copy" option to "svn checkout".
> >
> > 3. Add a "prepare-edit" command to "svn" that will copy the
> > working copy into the base copy (if the checksums match).
> >
> > 4. Add a cleanup-base-copies to "svn" that will recursively remove
> > the base copies from the current directory down.
> >
> > 5. Change the commit/merge to send the whole working copy instead
> > of fetching a base copy from the server and send back the diff,
> > if the .svn does not contain the base copy.
> >
> > Does this sound like a plan? I am willing to work on it, if the
> > more experienced guys think this is a way to go.
> >
> > Comments? Flames?
>
> I think this is still the tip of the iceberg. libsvn_wc is a complex
> beast, and has assumptions about the existence of text-base
> *everywhere* throughout it. You've merely pointed out the most
> obvious places... which is a good start.
>
> But honestly, we're in feature-freeze right now, and making text-base
> optional is a HUGE task that involves practically rewriting all of
> libsvn_wc. I don't think there's any way this would be accepted into
> 1.0.
>
> And I should remind you that there are many people "lined up" to
> rewrite libsvn_wc for other reasons: some want opaque directory
> collections, some want the administrative data to live outside the
> working copy, some simply want better performance.
>
> In my mind, this massive libsvn_wc rewrite will be a big focus
> of Subversion 2.0 (1.1?) later on. It will involve many design
> discussions among many developers. It's not the kind of thing a lone
> developer can do on their own in a couple of weeks.
>
> If you really want to help the community, you can help us kill 1.0
> bugs, so we can get to 1.0 quicker. As a volunteer, you can certainly
> work on whatever you want... it's not for us to say. I just don't
> suspect that you'll get a lot of support for this kind of change right
> now. :-)
>
>
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
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 Mar 24 23:05:44 2003