cmpilato@collab.net wrote:
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.
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