[Hcoop-discuss] hcoop version control: yet another episode begins

[Terrence Brannon]

For some reason, each time we bring up the issue of an svn server, everyone
agrees and it never gets done. Each time I bring it up, I desperately need
it, but then resort to other options and then return to wishing it were here
centralized with my other stuff.

So, is there any possibility of setting up a task force which meets in
#hcoop on irc.freenode.net to get this done with once and for all?

I suppose we could also just do it via one of the hcoop mailing lists, but
whatever it takes, I think we really need to focus.

In the interest of subverting our focus, what version control systems should
we support besides svn? There are several out there - darcs, Arx, cvs, svn,
monotone. I should also mention that trac is an attractive overlay on svn
that I am also thinking might be a useful umbrella for all my open-source
escapades.


On 12/29/05, holmesbj at hcoop.net <holmesbj at hcoop.net> wrote:
>
> > I just had a need to do some development and have people on IRC look
> > at what I was doing as I did it so they could d/l it, try it and
> > feedback on it.
> >
> > Mike_L wanted public SVN as well...
> >
> > Let's talk about this and maybe get it going.
>
>
> This was brought up a long time ago and it was shot down because we had no
> way of tracking bandwidth used.  Back then we used Apache 1.3 and we
> couldn't host SVN, but now we are running Apache 2.0 and adding support
> for Subversion+WebDAV via Apache is quite simple.  Using Apache, all
> subversion bandwidth is loggable through normal Apache bandwidth
> monitoring methods.  Once the required modules (mod_dav, mod_dav_svn) are
> added, each user would be able to specify their repository in the apache
> config file (via domtool?) with something like the following:
>
> <Location /repos>
> DAV svn
> SVNPath /absolute/path/to/repository
> </Location>
>
>
> The svn and svn+ssh protocols (which run through svnserve) should not be
> used because they provide no way to track bandwidth usage and large
> subversion repositories open to the public can eat up a lot of bandwidth.
>
> Additionally, svn+ssh requires people to log in through their own ssh
> account, which does not work for public servers.  This can be a real
> headache and is probably not what most people want.
>
> As a side note, IIRC, the normal svn protocol (again, via svnserve) uses
> CRAM-MD5 for authentication and ssh is not required unless there are
> sensitive files in the repository being sent across the wire.
>
> Securing data through SVN+Apache is as simple as using https instead of
> http.  This has the added benefit of working through most firewalls. At my
> work, almost all outbound ports are blocked and I would be unable to
> access the server on port 3690, the svn protocol port, or port 22, SSH.
> HTTP and HTTPS are my only options.
>
> Subversion through Apache is done using the WebDAV protocol.  Both Windows
> and OS X have native support to mount drives via WebDAV and /I think/ it's
> done quite commonly on the OS X.
>
> One final note, all access attempts to Subversion through Apache would be
> logged which could track unauthorized attempts to access a private
> repository.  There is currently NO LOGGING for svnserve, which IMHO is a
> big failing of svnserve and the primary reason why I recommend that
> everyone use Apache+SVN for hosting on public servers instead of svn until
> this has changed.
>
> I've set up Subversion through Apache and through svnserve several times
> so if anyone needs help setting it up, just ask.  Documentation on setting
> up Apache+SVN can be found here:
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-6-sect-4
>
> - Brian Holmes
> IRC: holmesbj
>
>
>
> _______________________________________________
> Hcoop-discuss mailing list
> Hcoop-discuss at hcoop.net
> http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hcoop.net/pipermail/hcoop-discuss/attachments/20060526/9f3f757c/attachment.htm