Going to follow up on these comments on the mailing-list, since the
discussion might drag on a bit. Will add the decided course of action
to the issue when a decision is made.
issues@subversion.tigris.org wrote:
------- Additional Comments From sussman@tigris.org 2003-01-27 08:39 PST -------
Hey Nuutti, I wanted to detail two different solutions here, after a
bunch of discussion between me/cmpilato/kfogel:
Solution One:
This is what Mike Pilato suggested. Basically, imitate ra_dav's
checkout method within libsvn_client. That is, do a depth-first
recursion, but as soon as you enter a directory, call RA-list() to
get a list of all children. Use that child-list to create a
complete entries file in memeory, and then write the complete
entries file all at once. Then start fetching children. This
guarantees that if the checkout is interrupted, the entries file is
always complete, and 'svn up' will always be able to finish the
checkout.
Understood - this is what pretty much exactly what I realized on my
own as well. Imitating ra_dav's checkout method was my plan, but I
didn't think of the generalization to libsvn_client.
I thought about going for this, but the more I thought about it, the
more it felt like an add-on solution to a problem that could be solved
by design change.
Solution Two:
Add a new interface to the update reporter API. We currently have
an old interface in which libsvn_wc says: I know that my entries
file is complete, but I'm missing some working files or dirs. We
would add a new interface which says: I have no idea if my
entries file is complete or not -- here's my list of entries.
(This is essentially the way CVS updates work.)
Yup, same idea - although a with a slight twist. More on that later.
The trick is that we don't want to use the new interface all the
time; it's pretty inefficient. So we need to create some kind of
marker (new file? new entry tag?) that indicates that libsvn_wc is
*certain* that the entries file is complete. The libsvn_wc update
editor could drop the marker when close_directory() is called. When
the checkout is interrupted, a whole bunch of missing directories
will be missing the marker, and thus 'svn up' will use the new
interface to rebuild the directories and finish the checkout.
Exactly - I agree with every bit of this.
I think that both of these solutions are essentially assuming that
if 'svn co' is interrupted, then 'svn up' is the way to finish the
checkout. That seems fine to me.
Yes, this is what I arrived as well.
------- Additional Comments From kfogel@tigris.org 2003-01-27 08:43 PST -------
Some clarifications about Solution Two (which I personally like :-) ):
I started to prefer that as well the more I thought about it.
The important thing about our current missing item report is that
it has to tell the server the missing items by name. That is, it's
for when the working item is missing, not the entry itself. We
don't (currently) have a way to tell the server I've got directory
foo at revision N, but I might be missing some entries. Here are
the ones I have, now you tell me what I don't have.
Yup, the basic problem of the current interface - client knowing only
what it has and the server wanting to know what is missing.
Also, just confirmed with Ben that where he wrote missing
directories missing the marker, he meant to write nested
directories missing the marker.
Yes.
Now, all this makes sense - but it leaves the question I presented on
the list unaswered - it was not very well formed, for I had not slept
in ages.
Namely - supposing that we have this new interface - and we can tell
that this directory is incomplete, please send me everything I don't
have.
How do we build a transaction that represents this? How do we build
something that when diffed against the actual repository revision
will bring in everything that is under some path, but not mentioned?
***
Then a small difference in thought patterns - I am not sure if it will
be useful or not, but it helped me see things.
The thing which I realized when thinking about the problem further was
that we do not _really_ lack a way of telling that I am missing some
entries. What that really means is that the directory in question is
kind of missing - but there are completed things transferred from
under it. And what we are missing is a way of saying that I am
missing this directory, send it to me, but don't send these few
directories, I already have them.
***
And then a small rant on how things could be.
If life were perfect, what we could do with the svn_ra_reporter_t
interface would be to exactly describe in nested features what the
working copy possesses, what it doesn't, what it needs and what it
doesn't care about. And this would be fine-grained to contents and
properties as well.
- On each item, three different cases could be told:
- I don't have this, send it to me in full
- I don't care about this, don't tell me anything about it
(for non-recursive and single file working copies)
- I have this, and my version is revision x
- And for each item, there would be three parts:
- Everything - I don't even have a proper entry for this
- For files: Contents, properties, entry info
- For directories: Contents recursively, properties, entry info
- Properties - I don't have the properties for this item
- For both: just the properties
- Content - I don't have the contents of this item
- For files: send me the full text-base
- For directories: incomplete, send all entries not mentioned
And this all could be just simply three methods, 'set_path',
'skip_path', 'delete_path', which all take an enumeration of BOTH,
CONTENTS, PROPERTIES as an argument.
But, this is increasingly megalomaniac - I am not planning on
implementing any of this, just food for thought I guess.
***
Anyway, to wrap it up - I am now blocking on that one question I have,
how do I build the transaction. I will be digging into that one deeper
myself, when time permits, as well. But after that's settled, then
it's a simple case of figuring out good names for the new interfaces,
and then I start coding.
-- 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:20:16 2006