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

Re: Crazy 5-step plan to remove the cached pristine copy

From: Florin Iucha <florin_at_iucha.net>
Date: 2003-03-24 16:37:03 CET

On Sun, Mar 23, 2003 at 10:18:53PM -0600, Ben Collins-Sussman wrote:
> florin@iucha.net (Florin Iucha) writes:
>
> > 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.
>
> 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.

Is there any use of the base copy, other than diffing the working copy
against it? OK, revert. Aything else?

> 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.

Clear as an unmuddied lake, sir!

> 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.

I don't want to rewrite it. I want to do the least-intrusive
changes...

> 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. :-)

Well, I have three pet issues with subversion right now:
   - single-step (atomic) renames
   - mandatory locks
   - no base copy "penalty"

Unfortunately the first one is big, with merge and dump/restore
implications. The second one looks big according to "locking-plan.txt".
The third one looked like it can be broken in smaller and
self-contained and meaningful pieces.

florin

-- 
"NT is to UNIX what a doughnut is to a particle accelerator."

  • application/pgp-signature attachment: stored
Received on Mon Mar 24 16:49:24 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.