On Mon, Nov 27, 2000 at 04:56:27PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@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/
Received on Sat Oct 21 14:36:15 2006