> > 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. 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.
>
> You don't have to run Subversion's web server on port 80. You can
> have your usual web server running on port 80, and Subversion on some
> other port (we do this on http://www.red-bean.com:8080/, for example).
>
> Heck, you can even run it on CVS's port 2401 if that's what your
> firewall requires, although of course it won't speak the CVS protocol.
>
> We're just considering Apache 2.0 to be part of the server code -- one
> of many things you need to run Subversion. This seems reasonable to
> me, since it doesn't have to interfere with your other server(s).
>
> Is there some other reason (besides the port interference non-issue)
> why this is a showstopper for you?
The first and biggest obstacle is that the members of my team don't have
expertise in setting up a web server. Network administration and network
coding are far from our area of expertise. CVS does not require you to be
an expert in anything to install and use it. Subversion obviously requires
more work and greater expertise to get your repository up and running. Do
you not consider this to be a significant drawback?
Second, we don't make the security policies for our servers, nor do we
manage the servers ourselves. It is VERY difficult to convince our
sysadmins to open a port for any reason. We can't even telnet or ftp to the
machine hosting our CVS repository. All access is via ssh only. CVS access
is also through ssh, not port 2401. They do have an Apache server without
WebDAV running on port 80. I seriously doubt we would be allowed to run a
web server of any type on another port, even if we knew how.
So I guess I don't know if it would be possible for us to run svn; I doubt
it would be allowed; and figuring out whether it's feasible is more work
than it ought to be.
We've run into the same frustrations with CVS as everyone else. I was
excited to hear about subversion with all of its improvements over CVS. I'm
disappointed to discover that it is geared primarily towards those that want
to be another SourceForge. Sure, if you're already installing/maintaining a
web server, the extra effort to support subversion is minimal. But surprise
surprise, most people are NOT already setting up a web server in their
development environment. I really think you're leaving a lot of potential
users out in the cold because they can't or don't want to set up a web
server to host their repository. I'm sure MANY will feel that the cost is
too high for the benefit.
I apologize for the hostile tone of this message. I'm just surprised that
you think this is such a non-issue.
Some more messages have come in...I'll pop some of their comments in here.
> > 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?
I mean "send bytes over a socket, optionally encrypting them." I also mean
encrypting them using the protocols and ports supported by the security
constraints in which I and many others work. Sending encrypted bytes using
ssh is a better solution for us because the server is already configured
this way. Using SSL requires significantly more work, and may not be
allowed anyway, as explained above.
> 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"?
It actually means anything accessible through any means other than SSH,
including that which can be accessed with a web browser, HTTP on any port,
gopher if your server supports it, even SSL, etc. All such content is
subject to much tighter security constraints than files available from a
shell.
> > 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.
Problem? Just a fact of life here. It makes a lot of sense to me. I
really shouldn't have to justify my organization's security policies (I
can't influence them anyway), so I won't. Just because a security
constraint causes me headaches doesn't mean it isn't necessary.
> Then let them ssh in and run svn over ra_local.
That machine neither mounts nor is mountable by any other machine (another
security constraint). Let's see now, everyone develops/compiles/tests on
the same machine...code only supports that single platform...what a great
idea! Actually, we tried that when we had our repository behind another
firewall. We used to FTP code back and forth between sites and run CVS
operations locally. Talk about a nightmare. People would get lazy and only
copy the files they modified, or they wouldn't copy over the CVS Entries
file. Files updated by CVS didn't always get pulled back across the
firewall to a working directory. It seemed like any non-trivial commit
ended up stomping someone else's changes. That mode of working lasted about
a week.
> That was the basic idea -- reuse wheels. How else could we possibly
> go from zero to self-hosting just over one year?
>
> Writing a server and a protocol is NOT a trivial thing.
I appreciate that. I appreciate all the benefits you get for free or nearly
free by leveraging existing tools. And it was wise to start with a modular
design. My point is that there are a lot of people running cvs that won't
be able to run svn due to the current integration with Apache. I believe
that I am one of them. The fact that there is no overlap in the
communication mechanisms used by cvs and those used by svn will be a problem
for many. Add in the relative difficulty in setting up a repository when
compared to CVS and I think you'll have a hard time winning people over.
> You are not looking at it from the right perspective.
Actually, I think it would do you some good to look at things from MY
perspective, if just for a minute. I'm a perfect example of the type of
user you should be catering to. I'm not at all qualified to write code for
you guys. I'm not very familiar with network coding, and only as familiar
with version management as I need to be. I don't manage a web server. I
don't have root access to my own machine. I definitely don't have
administrative priviledges on the machine we've got our CVS repository on.
Those who do have administrative priviledges are likely to deny or ignore
any requests I make to modify the server's configuration. Most of your
potential users fit that same description. If you can't win me over, how do
you expect to win over the masses?
I firmly believe this is a bigger issue than you as a group seem to consider
it.
Thanks,
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 02:54:52 2002