[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: <naked_at_iki.fi>
Date: 2003-01-29 00:06:09 CET

cmpilato@collab.net wrote:
 Or is there a better way to solve all this that I just haven't
 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.

I want a clarification - though I have a guess of the answer myself.

Can the ra_dav checkout model be generalized into update as well? With
this I mean that if an update results in the creation of a directory,
can that directory creation behave like the ra_dav checkout behaves -
first fetching the entries list and then fetching the entries - or is
the process there decidedly different. Since, now we know, that right
now, interrupting an update that creates a directory will result in
the very same problems that interrupting a checkout.

If the answer is that yes, it can - then that is what must be done
to update as well. If the answer is that no, it can't - then this
I can't see how this solution can work.

-- Naked

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:23:01 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.