Subversion meeting in San Francisco, 9am Wednesday 17th May

[Karl Fogel <kf...@galois.collab.net>]

Anyone interested in attending a design presentation and Q-&-A session
on Subversion on Wednesday the 17th in San Francisco, please come.
We're hoping to get some useful feedback.

Where:  457 Bryant Street
        San Francisco, CA

-Karl

Re: [subversion-dev] Subversion meeting in San Francisco, 9amWednesday 17th May

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

On Mon, 15 May 2000, Patrick Bihan-Faou wrote:
>...
> From: "Greg Stein" <gs...@lyra.org>
>...
> 
> > I agree with you on this one :-) ... My hope for subversion is to see it
> > use WebDAV for the protocol, Apache/mod_dav for the server, and mod_dav's
> > plugin mechanism to talk to the subversion repository.
> 
> Ah ah, trying to sell your web_dav module, I see!! :-)

hehe...

Truthfully: I just want to see WebDAV used as "the" versioning protocol on
the Internet. Whether that takes place with Client X or Server Y, I don't
mind.

I *do* want to see mod_dav (which in turn means Apache 2.0) be able to
talk to a CVS backend and the new Subversion backend.

> I am interested in doing that kind of work (hooking web_dav with CVS and/or
> subversion), however I don't know of any dav client that supports
> versioning. So testing the beast is going to be tough at best...

I released mod_dav before *any* client existed. I tested with Python
scripts. It is a simple chicken and egg problem, but one that didn't
bother me. I simply got the honor of declaring the first publicly
available WebDAV code, so I didn't mind :-)

> Also as for everybody else, this will be done on my spare time, which I
> currently use for sleeping :(.
> 
> If you have any pointers / ideas, please feel free to send them to me.

There has been discussion about custom backends on the dav-dev mailing
list. You can see the archives at:

    http://mailman.lyra.org/pipermail/dav-dev/

I can provide more specific followups if you start to dig in. Note that a
couple other people have expressed similar interest and may actually be
starting some work.

Cheers,
-g

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

Re: [subversion-dev] Subversion meeting in San Francisco, 9amWednesday 17th May

[Patrick Bihan-Faou <pa...@mindstep.com>]

Hi Greg!

----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>

> I agree with you on this one :-) ... My hope for subversion is to see it
> use WebDAV for the protocol, Apache/mod_dav for the server, and mod_dav's
> plugin mechanism to talk to the subversion repository.


Ah ah, trying to sell your web_dav module, I see!! :-)

I am interested in doing that kind of work (hooking web_dav with CVS and/or
subversion), however I don't know of any dav client that supports
versioning. So testing the beast is going to be tough at best...

Also as for everybody else, this will be done on my spare time, which I
currently use for sleeping :(.

If you have any pointers / ideas, please feel free to send them to me.

Patrick.

Re: [subversion-dev] Subversion meeting in San Francisco, 9amWednesday 17th May

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

On Mon, 15 May 2000, Paul D'Anna wrote:
> >From the server side, I can see that having Apache/mod_dav leverages
> building a separate server for subversion, allowing subversion to focus
> entirely on just repository functions and become a repository engine only
> (not a bad thing).

I completely agree. I have posted a couple times here, stating that I
believe the problem should be broken down into four parts:

1) client tools
2) network protocol (IMO: WebDAV)
3) server (IMO: Apache/mod_dav/subversion-backend-glue)
4) repository: Subversion

This gives us a nice divide-and-conquer approach. Even better: since
WebDAV is spec'd(*) and Apache/mod_dav is coded, then parts (2) and (3)
are greatly simplified for the Subversion effort.

The paper that Karl has been working on slots very nicely into (4). I
believe the initial client tool would operate exactly like today's "cvs"
tool, but speaks a different protocol out the back side (and *only* speaks
over the network; no multiple access mechanisms here)

(*) WebDAV core is RFC 2518. "DeltaV" is the versioning part and the
    latest draft is available at http://www.webdav.org/deltav/. The draft
    is the third in this series, but it follows on a prior series, so it
    has gone thru many more iterations than it would appear. Note that
    mod_dav already implements a plugin interface for "basic" versioning
    as specified in the draft.

> What if any is the performance hit where the server would
> be used as a regular web server as well?

None. It is a web server. If requests come in for pages, they get served.
If a request comes in to fetch history information, it is served. If you
have separate servers, these requests must be served, too, so the total
processing is going to be the same in both cases.

I might even argue that Apache would provide benefits over a separate
server. Since you have a single executable, the working set could be
lower. Apache has been tuned, it is multi-threaded (in Apache 2.0), etc.
All of that would need to be redeveloped if a custom server were to be
built.

> Or is the assumption that a mod_dav
> enabled server is dedicated for subversion only.

I'm not assuming this, but an administrator could definitely set it up
this way. For example, they could run a server on a different port which
only served Subversion repositories.

IMO, the administrator would do something like this:

# set up my Subversion repository at /rep
<Location /rep>
  DAV subversion
  DAVParam svn-root /home/svnroot
  Require group svnusers
</Location>

The above config says "use the subversion backend; set the 'svn-root'
parameter [consumed by the 'subversion' backend] to /home/svnroot; only
all users in the 'svnusers' group to access the /rep URL space."

> Would there ever be a need
> to have a non-Apache type of server for the repository and require a
> separate subversion protocol to access it?

Not in my view of the world :-)

The question is what requirement a separate protocol would be fulfilling.
If the WebDAV protocol cannot provide all the features that Subversion
needs, then the WebDAV design has not met its goal.

> >From the client side, I agree that supporting existing protocols would ease
> the conversion effort. But there also has to be back end conversions as well
> to import from other repositories into subversion.  A least one from CVS to
> subversion to start with.

Agreed.

Note that I believe supporting the old protocol is *only* necessary
because we cannot provide replacement clients for all of the ones in use
today. For example, I presume we would provide a new set of command-line
clients for Unix-like operating systems. But what about WinCVS, MacCVS, or
Pharmacy replacements? What about the tools that have been written to
speak the CVS protocol?

Given those backward-compatibility "needs", I suggest a proxy. I do not
believe that the CVS protocol can meet our needs moving forward, but it
would be a disservice to ignore existing tools. Finally... I quoted
"needs" because while some people view it as a "need", I'm perfectly happy
to tell people "sorry: that tool does not work against this repository; go
get client FOO." In other words, I can see the need, but I'm not about to
write code to fulfill it :-)

> On your final thought: Existing clients that don't support WebDav needing
> some type of proxy to WebDav ... hmm .. I like it.

IMO, it is only there until people can upgrade. It is a crutch, and may
provide a subset of the complete CVS functionality. For example, it might
not support the "annotate" CVS operation or allow tagging to occur. A
proxy is also the easiest thing to write, rather than another protocol
server that operates against the Subversion repository. (for N reasons
that I won't detail unless somebody wants to argue the point :-))

But hey... it sounds like we're on the same wavelength :-)

Cheers,
-g

p.s. slightly off-topic, but I also have an app named "ViewCVS" that I
would gladly update/change/whatever to operate against Subversion
repositories. Info at http://www.lyra.org/viewcvs/. You can see it in
operation at http://www.apache.org/websrc/viewcvs.cgi/

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

Re: [subversion-dev] Subversion meeting in San Francisco, 9amWednesday 17th May

[Paul D'Anna <pd...@iname.com>]

building a separate server for subversion, allowing subversion to focus
entirely on just repository functions and become a repository engine only
(not a bad thing). What if any is the performance hit where the server would
be used as a regular web server as well? Or is the assumption that a mod_dav
enabled server is dedicated for subversion only. Would there ever be a need
to have a non-Apache type of server for the repository and require a
separate subversion protocol to access it?

the conversion effort. But there also has to be back end conversions as well
to import from other repositories into subversion.  A least one from CVS to
subversion to start with.

On your final thought: Existing clients that don't support WebDav needing
some type of proxy to WebDav ... hmm .. I like it.

Paul D'Anna
(650) 592-8755
pdanna@iname.com

----- Original Message -----
From: Greg Stein <gs...@lyra.org>
To: <de...@subversion.tigris.org>
Sent: Monday, May 15, 2000 1:23 AM
Subject: Re: [subversion-dev] Subversion meeting in San Francisco,
9amWednesday 17th May


> On Fri, 12 May 2000, Patrick Bihan-Faou wrote:
> >...
> > Antoher thing I would like to play with is some sort of server plug-ins
to
> > offer files from a subversion DB to CVS clients of webdav clients or
other
> > things as they mature... From what I can see, it should be possible to
offer
> > at least the level of functionality of "older" protocols. This would be
a
> > great migration path for a lot of people.
>
> I agree with you on this one :-) ... My hope for subversion is to see it
> use WebDAV for the protocol, Apache/mod_dav for the server, and mod_dav's
> plugin mechanism to talk to the subversion repository.
>
> It seems like it would be possible to write a CVS protocol to WebDAV proxy
> thingy. Dunno what priority that I would give it, but I've got to believe
> somebody out there is up for doing it.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

Re: [subversion-dev] Subversion meeting in San Francisco, 9am Wednesday 17th May

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

On Fri, 12 May 2000, Patrick Bihan-Faou wrote:
>...
> Antoher thing I would like to play with is some sort of server plug-ins to
> offer files from a subversion DB to CVS clients of webdav clients or other
> things as they mature... From what I can see, it should be possible to offer
> at least the level of functionality of "older" protocols. This would be a
> great migration path for a lot of people.

I agree with you on this one :-) ... My hope for subversion is to see it
use WebDAV for the protocol, Apache/mod_dav for the server, and mod_dav's
plugin mechanism to talk to the subversion repository.

It seems like it would be possible to write a CVS protocol to WebDAV proxy
thingy. Dunno what priority that I would give it, but I've got to believe
somebody out there is up for doing it.

Cheers,
-g

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

Re: [subversion-dev] Subversion meeting in San Francisco, 9am Wednesday 17th May

[Patrick Bihan-Faou <pa...@mindstep.com>]

Hi,


----- Original Message -----
From: "Karl Fogel" <kf...@galois.collab.net>

> Anyone interested in attending a design presentation and Q-&-A session
> on Subversion on Wednesday the 17th in San Francisco, please come.
> We're hoping to get some useful feedback.
>
> Where:  457 Bryant Street
>         San Francisco, CA


How many people will be attending this so far ? I would be really happy to
meet you then, but unfortunately I am not going to SF before the end of the
month :(...

I haven't had time to describe why I am following the list, but basically
the aspects that interest me the most are the distributed repository. As
soon as I have some spare time, I will probably try to get involved a bit (a
lot) more...

Antoher thing I would like to play with is some sort of server plug-ins to
offer files from a subversion DB to CVS clients of webdav clients or other
things as they mature... From what I can see, it should be possible to offer
at least the level of functionality of "older" protocols. This would be a
great migration path for a lot of people.

My expertise is in network protocols. I worked for Gandalf/Mitel and now as
a consultant for Ericsson (developping Voice over IP for them).


Maybe I can meet you guys when I get in SF ?

Patrick.

Re: [subversion-dev] Subversion meeting in San Francisco, 9am Wednesday 17th May

[Karl Fogel <kf...@galois.collab.net>]

"Paul D'Anna" <pd...@iname.com> writes:
> Other than the current 1.50 spec, is there anything else going on with
> Subversion I should be up to speed on to be an intelligent observer?
> 
> I look forward to seeing your presentation.

Yes, a lot has changed.

Jim Blandy, Ben Collins-Sussman, and I are holed up here in Chicago
working on the design; there will be some changes from the 1.50 spec
you see, but the goal of the project is not changing.

So if you've read the 1.50, that's about as prepared as you can be for
next Wednesday.  Glad we'll see you there!

-Karl

Re: [subversion-dev] Subversion meeting in San Francisco, 9am Wednesday 17th May

[Paul D'Anna <pd...@iname.com>]

Other than the current 1.50 spec, is there anything else going on with
Subversion I should be up to speed on to be an intelligent observer?

I look forward to seeing your presentation.

Paul D'Anna
(650) 592-8755
pdanna@iname.com

----- Original Message -----
From: Karl Fogel <kf...@galois.collab.net>
To: Tara Hernandez <ta...@tequilarista.org>; Brian Behlendorf
<br...@collab.net>; <cy...@bluemartini.com>; <do...@bluemartini.com>;
<de...@subversion.tigris.org>
Sent: Wednesday, May 10, 2000 8:24 AM
Subject: [subversion-dev] Subversion meeting in San Francisco, 9am Wednesday
17th May


> Anyone interested in attending a design presentation and Q-&-A session
> on Subversion on Wednesday the 17th in San Francisco, please come.
> We're hoping to get some useful feedback.
>
> Where:  457 Bryant Street
>         San Francisco, CA
>
> -Karl
>