Re: Alternatives for remote access?

On Thu, Aug 29, 2002 at 02:42:38PM -0600, Darryl Melander wrote:
> I'm sure this topic has come up a million times. Here is one discussion I
> found in the archives:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=13460. Still,
> I'd like to make my comments on the bikeshed...

As a software engineer that spends his days reinventing(TM) wheels(TM)
I find the fact that the subversion team succedded in reusing so much
code and protocol design AWESOME!

> Are there plans to develop a remote access method that is not based on
> Apache, WebDAV, and deltaV? It seems odd to me that a project intent on
> displacing CVS has chosen not to support a single remote access method
> supported by its predecessor.

As in "send bytes over a socket, optionally encrypting them"?

Or do you really need to access a subversion repository using cvs?

> There are many situations where access to the repository via Apache just
> isn't feasible. You may not have control over which web server is intalled,
> or which options/libraries are included.

Compile it to your taste and run it from your $HOME.

> You may not be allowed to place
> content in a web-visible location.

What is a "web visible" location? Stuff available with a web browser?
Does that include applications accessible through a java applet in a
browser? Is gopher "web visible"?

> You may have a tight review and approval
> process for content accessed through a web server, where content accessible
> via a shell has a less stringent review policy.

That to me seems more like a problem with your workflow/security
process.

> You may not be allowed to
> make the required adjustments to the firewall. It may be more practical for
> you to get shell accounts for your team than to get the appropriate web
> security in place.

Then let them ssh in and run svn over ra_local.

> The bottom line for me is that my project will not be able to use Subversion
> until remote access is possible with an access protocol other than ra_local
> and ra_dav. I have other concerns as well, but this is an absolute
> show-stopper for my organization.

You are not looking at it from the right perspective.

> I believe that the tight coupling between
> web server and repository is a HUGE negative, one that will allow CVS to
> retain the upperhand for many (if not most) of those currently hosting a CVS
> repository.

It is a huge positive since they got somebody else to test and debug 60%
(I am making this number up) of the code required to support client
server operation.

> I get a kick out of this comment from the documentation:
>
> > Feel like writing a new network protocol for
> > Subversion? Just write a new library that
> > implements the RA API!
>
> LOL! That's quite a big JUST.

OK, Just pay somebody to do it.

florin

-- 
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6  03EE 34B3 E075 3B90 DFE4