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

Re: changing the checkout process

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-15 19:28:57 CEST

Ben Collins-Sussman wrote:

>Again, another RFC, resulting from a whiteboard session last week.
>Wanted to run it by the list first.
>The proposal is to drastically simplify the way we do checkouts.
>At the moment, every RA layer is responsible for implementing its own
>RA->checkout() routine, which essentially loops over dirents (just
>like RA->ls() does) and pushes data at the wc update-editor.
>Instead, we could make svn_client_checkout() do this:
> 1. create a wc root directory with nothing but a THIS_DIR entry,
> URL, revnum, and 'incomplete' flag.
> 2. call svn_client_update(). It will report the directory as
> incomplete, and the server will add all children.
>This change would effectively make checkouts rely completely on
>svn_repos_dir_delta(), rather than on independent RA looping
This sounds like an eminently sensible approach. It's also a step
towards the (conceptual) "svn fetch" that Greg and I had wished for
years ago.

>The pros:
> - we lose a lot of code from all three RA layers
> - our checkout logic is unified (easier maintenance, in theory)
> - for people creating new RA layers, one less routine to write
Any simplification of the RA API is pre-+1'ed by me.

>The cons:
> - this approach may give people the willies. I mean, come on... a
> checkout is just an update of an broken root dir?
Presumably, people with willies are men enough to handle the pressure... :-)

>Any thoughts?
What happens to memory usage on the server? Does it have to keep a delta
of the whole tree in memory, or is that representatino optimal (e.g.,
WRT single-rev subdirectories).

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 19:29:57 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.