copy-on-update (was Re: svn commit: r26471)

[Ben Collins-Sussman <su...@red-bean.com>]

On 9/5/07, Malcolm Rowe <ma...@farside.org.uk> wrote:
> On Wed, Sep 05, 2007 at 01:49:05PM -0700, sussman@tigris.org wrote:
> > Merge copy-on-updates branch to trunk.
> >
>
> Nice.  Does it work? (the only reason I ask is that you only added a
> single XFail test, so I'm not sure what the status of the branch is
> currently).

No, the feature doesn't actually exist yet.  All that branch work was
simply to change our internal architecture so that the behavior we
want *can* be written.

The new behaviors are:

  * the server now supplies copyfrom arguments to add_file() during an
update, if applicable.

  * if the server passes copyfrom args to add_file(), it also might
follow up with apply_textdelta() against the copied file.

  * the update_editor responds to the copyfrom args by doing an
svn_ra_get_file() off to the side to install the file, so that it's
ready for any subsequent textdeltas.

  * the update_editor is now ready to "grow some smarts" -- execute
some algorithms to figure out whether it already has the file in the
wc.  The svn_ra_get_file() call should (in theory) be the last-ditch
fallback behavior.

Note that I'm going for the 80% solution here -- solve the most common
cases of user pain.  We're not handling directories, only files.  What
I'd really like help with is now is designing some algorithms to
locate files in the WC.

Another snafu:  how do we know if an WC file is the file we want?  For
example, if the server sends copyfrom args of "foo.c@7", and the
client notices that it has foo.c@8, how does it know if that's the
same thing?  It makes me wish we had an RA call to do node-id
filesystem comparisons.


> One other comment: it'd be nice if we were able to make libsvn_client's
> file_fetcher slightly smarter, so that it's responsible for opening the
> second RA session on-demand.  Otherwise, we'll always open an extra
> connection to the server every update, even if we don't need it for
> anything.  This seems like a waste of server resources.

Good idea!  Patches welcome.  :-)

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

Re: copy-on-update (was Re: svn commit: r26471)

[Ben Collins-Sussman <su...@red-bean.com>]

On 9/6/07, David Glasser <gl...@davidglasser.net> wrote:
> On 9/5/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > On 9/5/07, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > > On Wed, Sep 05, 2007 at 01:49:05PM -0700, sussman@tigris.org wrote:
> > > > Merge copy-on-updates branch to trunk.
> > > >
> > >
> > > Nice.  Does it work? (the only reason I ask is that you only added a
> > > single XFail test, so I'm not sure what the status of the branch is
> > > currently).
> >
> > No, the feature doesn't actually exist yet.  All that branch work was
> > simply to change our internal architecture so that the behavior we
> > want *can* be written.
> >
> > The new behaviors are:
> >
> >   * the server now supplies copyfrom arguments to add_file() during an
> > update, if applicable.
>
> Not quite caught up post-Burning-Man with dev@ mail, but: did you rev
> the update APIs yet to provide a boolean to turn this behavior on, or
> do we still need to do that?  (Because old wc editor is stupid and
> totally ignores the copyfrom args, it is vital that a new server not
> try to send them to old clients.)

Not yet... it's definitely on my todo list.  Old clients are worse
than stupid... I believe they abort() if they receive copyfrom args.

So yeah, a new client would have to *explictly* request the new
update-behavior from the server, and the server may or may not be able
to provide it.

Wanna help with this?


> > Another snafu:  how do we know if an WC file is the file we want?  For
> > example, if the server sends copyfrom args of "foo.c@7", and the
> > client notices that it has foo.c@8, how does it know if that's the
> > same thing?  It makes me wish we had an RA call to do node-id
> > filesystem comparisons.
>
> Can't svn_ra_stat do that (and check the created_rev field)?  Although
> I feel like I've said this on IRC several times and maybe there was
> some reason I was wrong :)
>

Yeah, ra_stat will answer this question, you're right.  We just need
to get the algorithm correct.

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

Re: copy-on-update (was Re: svn commit: r26471)

[David Glasser <gl...@davidglasser.net>]

On 9/5/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/5/07, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > On Wed, Sep 05, 2007 at 01:49:05PM -0700, sussman@tigris.org wrote:
> > > Merge copy-on-updates branch to trunk.
> > >
> >
> > Nice.  Does it work? (the only reason I ask is that you only added a
> > single XFail test, so I'm not sure what the status of the branch is
> > currently).
>
> No, the feature doesn't actually exist yet.  All that branch work was
> simply to change our internal architecture so that the behavior we
> want *can* be written.
>
> The new behaviors are:
>
>   * the server now supplies copyfrom arguments to add_file() during an
> update, if applicable.

Not quite caught up post-Burning-Man with dev@ mail, but: did you rev
the update APIs yet to provide a boolean to turn this behavior on, or
do we still need to do that?  (Because old wc editor is stupid and
totally ignores the copyfrom args, it is vital that a new server not
try to send them to old clients.)

>   * if the server passes copyfrom args to add_file(), it also might
> follow up with apply_textdelta() against the copied file.
>
>   * the update_editor responds to the copyfrom args by doing an
> svn_ra_get_file() off to the side to install the file, so that it's
> ready for any subsequent textdeltas.
>
>   * the update_editor is now ready to "grow some smarts" -- execute
> some algorithms to figure out whether it already has the file in the
> wc.  The svn_ra_get_file() call should (in theory) be the last-ditch
> fallback behavior.
>
> Note that I'm going for the 80% solution here -- solve the most common
> cases of user pain.  We're not handling directories, only files.  What
> I'd really like help with is now is designing some algorithms to
> locate files in the WC.
>
> Another snafu:  how do we know if an WC file is the file we want?  For
> example, if the server sends copyfrom args of "foo.c@7", and the
> client notices that it has foo.c@8, how does it know if that's the
> same thing?  It makes me wish we had an RA call to do node-id
> filesystem comparisons.

Can't svn_ra_stat do that (and check the created_rev field)?  Although
I feel like I've said this on IRC several times and maybe there was
some reason I was wrong :)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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