> From: Darryl Melander [mailto:djmelan@sandia.gov]
>
> > > 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?
>
That's so not true. CVS does require you to be an expert in lots of
things to install it and use it well. Including making sure regular
backups happen, and all of the odd/fun situations that remote CVS
repositories get into. (wedged locks, etc...)
> 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.
>
This is very true, but sadly, you work where you work, and this is what
you have to deal with. In my opinion, Sandia security folks would need
to approve Subversion even if Subversion was as easy to setup as CVS,
and everybody could continue using ssh. Security folks == paranoia, and
I don't know whether you noticed it or not, but you have paranoid
security folks. I can't say I blame them too much atm. I feel for your
pain continuing to use CVS, but there's little we can do that would
speed up the process of getting Sandia to approve use of Subversion, no
matter what access mechanism Subversion has.
> 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.
>
No, actually, there's more overhead in supporting Subversion than a
normal generic web server. It's actually quite similar to supporting CVS
believe it or not. It has the same sorts of issues. Disk space, backups,
occasional operational attention, etc... Boring web servers can be much
less painful to deal with, especially depending on the content
deployment model.
> I apologize for the hostile tone of this message. I'm just surprised
that
> you think this is such a non-issue.
>
No, we know it's an issue for some folks. I don't think it should be an
issue for you though, because Sandia security should be approving any
external communication application including SSH, CVS, and Subversion.
Any issue persay would be with the security folks at Sandia. Sadly, it
doesn't sound like you have enough information to determine whether or
not Subversion's design is a real issue at Sandia.
>
> 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'm not worried about winning you over. I can tell we already have you
hooked by the Subversion feature list. Let us talk to the security
approval folks and we'll help you win them over. ;)
In terms of winning over the masses, I'm not terribly worried about that
either. Setup problems are easy (if indeed sufficiently annoying) to
engineer around, but convincing security audit teams to approve new
software is an entirely separate realm of problems.
I'd imagine that it'd be fairly easy to come up a compelling argument
for Sandia security to structure their security mechanism/requirements
around Subversion if the benefits over CVS are great enough.
Sadly, it may take a while until Subversion has built up an even bigger
reputation then the current mailing list traffic indicates until it
becomes clear to security audit teams that Subversion is worth
considering, but that's how such things go. You can't always have
everything you want.
Also remember, this is 1.0, we can't be all things to all people just
yet, we want to ship something soon, not continue churning out new
features for 3 more years. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 03:38:39 2002