heads-up: restartable checkouts

[Ben Collins-Sussman <su...@collab.net>]

I've "picked up the ball" on issue #730 -- restartable checkouts --
from Hadaka, with his permission.  I've spent a couple of days mulling
over the problem, reading all of Nuutti's notes, reading email
threads.  Then I discussed the problem with kfogel, cmpilato, gstein,
and jackr in front of a whiteboard; as a group, we came up with a good
solution that we're all happy with.  On IRC, I explained the solution
to mbk and sander, and they're happy with it too.  I *hope* that's
enough of a consensus to get moving.  :-)

Anyway, I'm relaying the strategy here, so nobody is caught by
surprise:

1. Instead of '0', create '-1' revnums when creating a fresh entries
   file containing only THIS_DIR.  (This is part of init_adm_area(), I
   believe.)

2. Modify update_editor.c:add_directory() create a link in its
   parent's entries file immediately, rather than having
   close_directory() do that.  close_directory() still will retain its
   job of changing the directory's revnum from -1 to something valid.

These two initial changes are goodness: it means that incomplete
entries files are now linked in their parent directories, so that an
update-crawler can see them.

3. On the server side, teach the libsvn_repos reporter functions to
   notice a invalid revnum (-1) passed into set_path() and
   link_path().  Rather than freak out, do any necessary linkage in
   the txn and then *remove* all children of the new directory.

4. On the client side, allow the update-crawler to report unfinished
   directories as being at revision -1; this puts the crawler into a
   new "low confidence" mode, akin to CVS.  Normally, the crawler
   assumes the entries file is complete, and thus only reports
   anomalous children, because client/server have a shared
   understanding of what 'directory version N' means.  But in this
   "low confidence" mode, the client believes the entries file is
   incomplete, and a) assumes the server has created an empty
   directory, and b) unconditionally reports *all* children that it
   sees in the entries file to the server.

In this new design, running 'svn up' in an working-copy of an
interrupted checkout will be able to successfully report on both
finished and unfinished entries files, complete the crawl, and receive
the tree delta from the server.

This solution also has a nice property: no compatibility headaches.
We don't need to change network protocols one whit.  An old client
will still choke on an unfinished entries file claiming to be revision
0 or -1.  An old server will still choke whenever a 0 or -1 is passed
into set_path().  In other words, nothing can get worse.  If either
client or server are old, checkouts continue to be un-restartable.
But if client and server are both new, then 'svn up' can finish the
checkout using the low-confidence reporting technique on unfinished
entries files.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2003-05-11 at 14:26, Branko Čibej wrote:
> >>Heh, and note that "svn co --depth=0" doesn't make sense, so "svn co -N"
> >>is quite unambiguous.
> >>    
> >>
> >
> >It doesn't make sense?  Shouldn't it create a working dir with no files
> >in it, so that I can svn pedit the directory or whatever?
> >  
> >
> No, it doesn't make sense. You can pedit a URL.

And if I want to pedit several properties and check them all in
atomically?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Branko Čibej <br...@xbc.nu>]

Greg Hudson wrote:

>On Sat, 2003-05-10 at 05:05, Branko Čibej wrote:
>  
>
>>Heh, and note that "svn co --depth=0" doesn't make sense, so "svn co -N"
>>is quite unambiguous.
>>    
>>
>
>It doesn't make sense?  Shouldn't it create a working dir with no files
>in it, so that I can svn pedit the directory or whatever?
>  
>
No, it doesn't make sense. You can pedit a URL.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2003-05-10 at 05:05, Branko Čibej wrote:
> Heh, and note that "svn co --depth=0" doesn't make sense, so "svn co -N"
> is quite unambiguous.

It doesn't make sense?  Shouldn't it create a working dir with no files
in it, so that I can svn pedit the directory or whatever?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:

>Branko Čibej <br...@xbc.nu> writes:
>
>  
>
>>Ben Collins-Sussman wrote:
>>[lots of things]
>>
>>Interesting plan. I wonder, though, if it's better than doing a
>>breadth-first checkout instead of a depth-first one, like we're doing now.
>>    
>>
>
>That's equivalent to tossing libsvn_wc/update_editor.c.  That is, it
>means coming up with a completely new breadth-first system for
>checkouts, one which doesn't involve using an editor at all.  I don't
>think any of us were comfortable with that idea.  At least for us,
>that would be a last-ditch strategy of desperation.  :-)
>
O.K.

>>What happens when you do "svn co -N repos; svn up"?
>>    
>>
>
>What is -N?  What does that mean, depth 0?  Depth 1?
>
Let's not be so pedantic, eh? Of course it means --depth=1 in this case;
I don't care about the name of the switch, its the semantics that are
important here. So, let me rephrase the question:

What happens if you do a non-recursive checkout of a directory, one that
only pulls its immediate children, and then run "svn up" in that working
copy? Does the update ignore the non-recursiveness of the checkout? Do
directory children even show up in a non-recursive checkout?

Heh, and note that "svn co --depth=0" doesn't make sense, so "svn co -N"
is quite unambiguous.

>I've made my opinion known before: I think we should banish the -N
>switch, because at the moment it's a) ambiguous, b) half-implemented
>for many commands, and c) inconsistent across commands.
>
No, we should just define what -N means for each specific command. It's
a useful shortcut, just like -R. So, a) and c) are only a problem until
the behviour is documented -- assuming, of course, that the rules for
chosing --depth=0 or --depth=1 behaviour are consistent and logical. b)
isn't going to go away just because the name of the switch changes.

>I'm very much looking forward to cmpilato's push to create a --depth
>argument as a replacement.
>  
>
Sure, so am I.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Ben Collins-Sussman <su...@collab.net>]

Branko Čibej <br...@xbc.nu> writes:

> Ben Collins-Sussman wrote:
> [lots of things]
> 
> Interesting plan. I wonder, though, if it's better than doing a
> breadth-first checkout instead of a depth-first one, like we're doing now.

That's equivalent to tossing libsvn_wc/update_editor.c.  That is, it
means coming up with a completely new breadth-first system for
checkouts, one which doesn't involve using an editor at all.  I don't
think any of us were comfortable with that idea.  At least for us,
that would be a last-ditch strategy of desperation.  :-)

> What happens when you do "svn co -N repos; svn up"?

What is -N?  What does that mean, depth 0?  Depth 1?  

I've made my opinion known before: I think we should banish the -N
switch, because at the moment it's a) ambiguous, b) half-implemented
for many commands, and c) inconsistent across commands.

I'm very much looking forward to cmpilato's push to create a --depth
argument as a replacement.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: heads-up: restartable checkouts

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:
[lots of things]

Interesting plan. I wonder, though, if it's better than doing a
breadth-first checkout instead of a depth-first one, like we're doing now.

What happens when you do "svn co -N repos; svn up"?


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org