svn_ra.h

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

Greg S. --

Perhaps we can start a thread on the status of svn_ra.h?  

I know that as the primary user of jimb's svn_fs.h, you two have been
negotiating and evolving it.  

Similarly, Karl and I are going to be the primary users of svn_ra.h.
I'd like to come up with a preliminary "design" of ra's interface, and
then let it grow from there.

Re: svn_ra.h

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

Greg Stein <gs...@lyra.org> writes:

> > So ra will need to make two editors available for driving:  one for
> > reporting a skelta to the repository, and one for committing.
> 
> Why? I don't understand what the first step is accomplishing. Are you
> talking about doing a "preflight" to see if the all of the changed files are
> current or something?
> 
> But we took care of that with the postfix delta. We can walk the tree,
> fetch version numbers and compare them, and after all that, then we upload
> the actual changes and commit them.
> 
> Why two steps?

Oh -- misunderstanding here.  There aren't two steps for committing.

When we commit, we simply send local mods to the editor.  That's it,
end of story.  As you said above, the repository can reject us at any
point, *before* we send all the postfix text-deltas.

The "new" crawler algorithm that I'm talking about is for *updates*.
When we want the repository to update our working copy, we first need
to tell the repository what our working copy looks like.  Then the
respository sends a custom update, patching exactly whatever is needed
to make the working copy resemble a pristine tree.

So the "new" crawler doesn't report local mods at all.  Instead, it
looks at the revision number of the working copy's root directory.
Then it crawls the working copy and reports only those files and dirs
whose revision numbers are *different*.  

(Of course, there are other ways to do this.  Once upon a time we had
odd visions of special data structures that allowed us to send a
"list" of all working copy revision numbers.  But it turns out that
you can give the repository a complete description by driving an
editor in this particular way.  It's less network traffic too.)

Re: svn_ra.h

[Greg Stein <gs...@lyra.org>]

On Tue, Nov 28, 2000 at 01:44:28AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > I think it also needs one when it is updating.
> > 
> >     crawler_editor => ra_editor => wc_editor
> >     
> >     "crawler finds an reports items to RA which fetches updates which
> >      applies them via WC"
> 
> Right.
> 
> Right now, adm_crawler.c is a program that recursively walks the
> working copy and reports local mods to an editor; it's the essence of
> the `commit` command.  But I need to write a smaller version of this
> program.  Specifically, one which notices nothing but revision
> numbers; it reports an object to the editor iff the objects' revision
> number is different than a particular "base" revision.   This is
> essentially our `skelta' idea from way back when. 
> 
> So ra will need to make two editors available for driving:  one for
> reporting a skelta to the repository, and one for committing.

Why? I don't understand what the first step is accomplishing. Are you
talking about doing a "preflight" to see if the all of the changed files are
current or something?

But we took care of that with the postfix delta. We can walk the tree,
fetch version numbers and compare them, and after all that, then we upload
the actual changes and commit them.

Why two steps?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: svn_ra.h

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

Greg Stein <gs...@lyra.org> writes:

> (this is also how Apache and mod_dav deals with name conflicts in the
> modules they load; also how I suggested we handle plugins oh so long ago)

Ah yes!  I remember -- the whole "plugin" architecture we talked about
last summer!  Neat.  Let's revive it.  We can mimic Apache this way.


> I think it also needs one when it is updating.
> 
>     crawler_editor => ra_editor => wc_editor
>     
>     "crawler finds an reports items to RA which fetches updates which
>      applies them via WC"

Right.

Right now, adm_crawler.c is a program that recursively walks the
working copy and reports local mods to an editor; it's the essence of
the `commit` command.  But I need to write a smaller version of this
program.  Specifically, one which notices nothing but revision
numbers; it reports an object to the editor iff the objects' revision
number is different than a particular "base" revision.   This is
essentially our `skelta' idea from way back when. 

So ra will need to make two editors available for driving:  one for
reporting a skelta to the repository, and one for committing.

Re: svn_ra.h

[Greg Stein <gs...@lyra.org>]

On Mon, Nov 27, 2000 at 04:56:27PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > > How does it know which one to use?
> > 
> > Default to DAV. If the repository URL is file://, then use local. Dunno
> > about the XML (or other, arbitrary RA libraries). I'd say some other switch
> > to select it.
> 
> Right... if we use `--xml-file'.  Sure.

Yup. But also consider that we might have a way of generating a big "diff
against the repository." Maybe XML is one of the output formats for that. We
can spit out context diffs, unified diffs, a patch file, or an XML (SVN)
patch file.

In that sense, we toss --xml-file and key off the format type.

And maybe there is an "apply patch" SVN operation; again, keying off the
patch type.

Just some blue sky thoughts. --xml-file as the UI and keying mechanism seems
okay, too :-)

> > > Can it have
> > > more than one loaded at the same time?
> > 
> > Not sure. I can't think of a case where two are needed.
> >
> > Hmm... maybe. Imagine a mixed-repository working copy. I don't know that we
> > need to support that in V1, but a given dir's RA is implied by some data
> > store in the SVN subdir.
> 
> Right.  But I think people would be annoyed if Subversion 1.0 didn't
> support mixed-repository working copies.
> 
> Suppose I have a working copy `foo/' such that it all comes from a
> far-away network repository -- except for one particular subdir
> `bar/', whose SVNROOT is repository on local disk.

Ah. Local. I was thinking some goofball writes libsvn_ra_cvs and wants a
mixed SVN/CVS repository or some such nonsense.

Yes... mixing local and remote would be a Good Thing(tm) for V1.

>...
> For gloo/ and bloo/, I need to use libsvn_ra_dav.  For bar/, I need
> libsvn_ra_local.  This means the client needs to manually load the dav
> library, then *un*load it, load the local library, then *un*load it,
> then load the dav library again.  It needs to make sure that they're
> never loaded at the same time, else we run into symbol namespace
> conflicts, right?

Nah. See my previous note about resolving the name conflicts.

(this is also how Apache and mod_dav deals with name conflicts in the
modules they load; also how I suggested we handle plugins oh so long ago)

>...
> > [ the "session" is a baton, if you will, for the entire sequence of
> >   operations. in the DAV case, it holds the HTTP connection to the server ]
> 
> Sounds like a nice, abstract idea.  The "session" may hold different
> data for ra_local.

Bing!

> > There will be a number of editors, but I only know of commit and update.
> 
> Yeah, I think that's all there is.  libsvn_wc provides an `update'
> editor that you need to drive when doing a checkout or update.

Right. This is the "consume" side of RA that I mentioned.

> And
> libsvn_wc needs to drive an editor when committing.

I think it also needs one when it is updating.

    crawler_editor => ra_editor => wc_editor
    
    "crawler finds an reports items to RA which fetches updates which
     applies them via WC"

> Right now it's
> driving Greg H's xml-output editor, but eventually it will need to
> drive one you provide.

*nod*

> I'll set up svn_ra.h as I see fit, and we'll go from there.  :)

Cool!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: svn_ra.h

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

Greg Stein <gs...@lyra.org> writes:

> > What's our mechanism for loading the appropriate DSO into the
> > command-line client?
> 
> apr_dso.h

Right.  I figured.  :)


> > How does it know which one to use?
> 
> Default to DAV. If the repository URL is file://, then use local. Dunno
> about the XML (or other, arbitrary RA libraries). I'd say some other switch
> to select it.

Right... if we use `--xml-file'.  Sure.

> > Can it have
> > more than one loaded at the same time?
> 
> Not sure. I can't think of a case where two are needed.
>
> Hmm... maybe. Imagine a mixed-repository working copy. I don't know that we
> need to support that in V1, but a given dir's RA is implied by some data
> store in the SVN subdir.

Right.  But I think people would be annoyed if Subversion 1.0 didn't
support mixed-repository working copies.

Suppose I have a working copy `foo/' such that it all comes from a
far-away network repository -- except for one particular subdir
`bar/', whose SVNROOT is repository on local disk.

So now I cd into foo/ and type `svn update gloo/ bar/ bloo/`.

For gloo/ and bloo/, I need to use libsvn_ra_dav.  For bar/, I need
libsvn_ra_local.  This means the client needs to manually load the dav
library, then *un*load it, load the local library, then *un*load it,
then load the dav library again.  It needs to make sure that they're
never loaded at the same time, else we run into symbol namespace
conflicts, right?


> [ the "session" is a baton, if you will, for the entire sequence of
>   operations. in the DAV case, it holds the HTTP connection to the server ]

Sounds like a nice, abstract idea.  The "session" may hold different
data for ra_local.

> There will be a number of editors, but I only know of commit and update.

Yeah, I think that's all there is.  libsvn_wc provides an `update'
editor that you need to drive when doing a checkout or update.  And
libsvn_wc needs to drive an editor when committing.  Right now it's
driving Greg H's xml-output editor, but eventually it will need to
drive one you provide.

I'll set up svn_ra.h as I see fit, and we'll go from there.  :)

Re: svn_ra.h

[Greg Stein <gs...@lyra.org>]

On Mon, Nov 27, 2000 at 02:23:24PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
> 
> > Even if you don't split out a libsvn_ra_xml, you can use libsvn_client as a
> > guide, based on where/when/how it does the XML stuff.
> > 
> 
> Assume that we have three libraries now: 
> 
>    libsvn_ra_dav
>    libsvn_ra_xml
>    libsvn_ra_local
> 
> And all three implement the interface in `svn_ra.h'.
> 
> What's our mechanism for loading the appropriate DSO into the
> command-line client?

apr_dso.h

> How does it know which one to use?

Default to DAV. If the repository URL is file://, then use local. Dunno
about the XML (or other, arbitrary RA libraries). I'd say some other switch
to select it.

> Can it have
> more than one loaded at the same time?

Not sure. I can't think of a case where two are needed.

Hmm... maybe. Imagine a mixed-repository working copy. I don't know that we
need to support that in V1, but a given dir's RA is implied by some data
store in the SVN subdir.

> Gimme a vision here.  :)

Sorry, don't have one :-). Like I said, I hadn't really had a chance to
apply much thought to the problem yet. Loading them thru apr_dso, use them,
and that's about it. Dunno what the API will end up being (particularly to
deal with the possibility of different needs/inputs for prepping an RA
"session". (e.g. how to get the HTTP user/pass into there?)

[ the "session" is a baton, if you will, for the entire sequence of
  operations. in the DAV case, it holds the HTTP connection to the server ]

There will be a number of editors, but I only know of commit and update.
Looking at libsvn_client will discover other editors. The checkout process
consumes an editor (to make changes in the WC). Really... an investigation
into libsvn_client to see what XML-related handling is used (generally, in
conjunction with WC), then to imply the same handling on RA in general.

As you go, we can certainly think about it some more, but that's about all
that I have right now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: svn_ra.h

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

Greg Stein <gs...@lyra.org> writes:

> Even if you don't split out a libsvn_ra_xml, you can use libsvn_client as a
> guide, based on where/when/how it does the XML stuff.
> 

Assume that we have three libraries now: 

   libsvn_ra_dav
   libsvn_ra_xml
   libsvn_ra_local

And all three implement the interface in `svn_ra.h'.

What's our mechanism for loading the appropriate DSO into the
command-line client?  How does it know which one to use?  Can it have
more than one loaded at the same time?  Gimme a vision here.  :)

Re: svn_ra.h

[Greg Stein <gs...@lyra.org>]

On Mon, Nov 27, 2000 at 01:31:51PM -0600, Ben Collins-Sussman wrote:
> 
> Greg S. --
> 
> Perhaps we can start a thread on the status of svn_ra.h?  
> 
> I know that as the primary user of jimb's svn_fs.h, you two have been
> negotiating and evolving it.  
> 
> Similarly, Karl and I are going to be the primary users of svn_ra.h.
> I'd like to come up with a preliminary "design" of ra's interface, and
> then let it grow from there.  

Please whack it into whatever shape that you'd like. I haven't applied my
brain to it yet, so I have no preconceived notions of what it should look
like.

So... I'd say for you to just bang out the API that you're thinking of, and
then I'll poke at it in a second pass as I work on the code.

You should be able to get a good idea of what it needs to look like if you
break the XML file handling out of libsvn_client and move it into
libsvn_ra_xml.
[ basically, whoever builds a "real" RA layer will be the first to flesh out
  svn_ra.h ]

Even if you don't split out a libsvn_ra_xml, you can use libsvn_client as a
guide, based on where/when/how it does the XML stuff.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/