[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-29 01:27:30 CET

Nuutti Kotivuori naked@iki.fi writes:

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

[...]

 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.

Checkout aren't restartable because when a checkout dies, some
directory is left with an entries file that contains lies. In a
checkout, the lie is usually very straightforward:

   I claim to have directory FOO at revision 0 (because my revision
   number doesn't get bumped until all my children are finished being
   checked out) and I am not missing of my childen (because nobody
   bothered to tell me the full list of children that I'm supposed to
   have, and since I have every child that is in my entries file, I
   think I am missing nothing).

Updates should never be in a dishonest state, though. If a directory
doesn't get fully updated, it's revision still reflects what it had
before the update (which was known to be complete and accurate) and
each of its children accurately reflect their state.

In other words, unless I have missed something really important,
updates do not have the same theoretical restart problem as do
our current checkouts. Yes, there may be bugs that are demonstratable
in update, but I'm quite certain (though prepared to be schooled on
the matter) that those are implementation oopses, not theoretical
issues.

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