On Tue, Oct 17, 2000 at 05:49:14PM -0500, Karl Fogel wrote:
> Greg Stein <firstname.lastname@example.org> writes:
> M1 got re-scheduled to this Friday, Oct 20th. I think we're doing
> okay for that, since we were mostly there already anyway. You should
> be able to hook up the networking code without disturbing or being
> disturbed by what's gone on elsewhere.
Since much of my focus is currently in mod_dav and mod_dav_svn, yes: it
should be pretty independent :-) Although I'll need the FS here soon...
> > What's our due date? Or is at all in my lap? (urk!)
> How long do you think we need to hook up both client side and server
> side (i.e., actually start using Apache)?
Getting a "checkout" to happen will be quite easy, actually. I just reviewed
svn_fs.h and it looks like opening/reading files and dirs will be very
I'd say just another day or two of coding. (of course, something else will
need to *put* content into the repository)
Next: we have update and commit to handle. Commit must provide for adding
files/dirs, changing files, and deleting files/dirs. [for this round] This
will be another good chunk, but it should fit in the three weeks you mention
> I'm trying to come up with a sequence of milestones, and estimate
> dates for them right now. Will get back to you on that. But rest
> assured that making m1 functionality happen over the wire is
> definitely the next milestone.
Right. If the above set of features doesn't sound right (e.g. you want to
throw property handling in :-), then we can adjust. Otherwise, I'll handle
updates and simple commits (no copying or renaming of files/dirs yet).
> If you think that will take longer than three weeks (of work, I mean,
> starting after you get back), then I'll have to reconsider some
> scheduling stuff. I'm guessing 3 weeks max, though, is that
> reasonable? (But please don't be afraid to send me bad news on a
> public list. :-) )
Seems reasonable so far. I'll flesh out the TASKS/STACK file and see how
> As I understand it, the whole point is that libsvn_ra_dav and
> libsvn_ra_local provide different implementations of the same
> interface (for those who are curious about the past discussion, the
> thread was "Subject: ra library -- philosophy").
> Now, what's in svn_ra.h might not be that interface yet (you mentioned
> that you threw it together quickly, although actually it looks pretty
> good to me).
Mostly, it is devoid of things like property handling, history reporting,
etc. All of that will need some kind of interface.
> But anyway, as long as we make sure that interface is
> not network-specific, implementing libsvn_ra_local is a task for the
> future -- just a matter of providing alternative functionality behind
> that interface.
> So I don't think we should spend time on libsvn_ra_local right now.
> Being truly networked, with Apache and the whole nine yards, is a
> higher priority, because that's what we need to replace CVS. The
> network code path is the one we must Get Right from the beginning.
> Let's concentrate on that.
Quite fine by me. As I mentioned before, I actually think that
libsvn_ra_local could end up as a crutch during development if we aren't
careful. ("I don't want to run Apache... just let me do my dev over this
little local loop here"; oops.. there goes testing for our main code path)
> It will be a fine day when we stop swapping these XML files back and
> forth and are actually sending DAV protocol over the wire. :-)
My mission in life! :-)
> So tasks are:
> - make sure you like the interface in svn_ra.h
> - make sure libsvn_ra_dav provides it
> Does that sound like a good place to start?,
The interface is fine with me. I just need to fill in the functions now. And
then the mod_dav and mod_dav_svn work.
Lessee... three weeks starting November 1. I'm all up for declaring M2 to
occur right before T-Day (somewhere in the 20th to 22nd) and then having
people take a break.
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:11 2006