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

Re: Issue 730 related question about svn_ra_reporter_t interface

From: <cmpilato_at_collab.net>
Date: 2003-01-27 16:54:58 CET

Nuutti Kotivuori naked@iki.fi writes:

 I'm not too sure how update works it magic, but what I have surmised
 is that first a transaction is built that represents the state the
 working copy, then that transaction is diffed against the revision to
 update to, and the differences are given through the
 svn_delta_editor_t interface to the working copy. Correct me or hint
 me towards a document if I have gotten it wrong.

Nope, your understanding is correct.

 Or is there a better way to solve all this that I just haven't seen?

I think the correct way to handle issue 730 is to move the dav
checkout model into libsvn_client so all RA layers can benefit. In
short, this model is:

   - fetch the top-level directory's props and a list of entries.

   - in an atomic fashion, create the .svn directory for that directory,
     populating its .svn/entries directories

     *** (if we are interrupted after this step, 'svn up' will see all
         missing children and fetch them, building out subtrees and all)

   - fetch each file in the entries list, loggily adding it to the
     working copy.

     *** (if we are interrupted after this step, 'svn up' will see
         perhaps some missing files, and all missing subdirs, and do
         the right thing)

   - for each subdirectory, do this whole process again (just down a
     directory level).

I *think* this will work for us beautifully. What's more, I think
that it can be basically accomplished using the RA get_dir and
get_file interfaces.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:19:37 2006

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.