This mail is an automated notification from the task tracker
of the project: Administration.
/**************************************************************************/
[task #118] Latest Modifications:
Changes by:
Timothee Besset <[EMAIL PROTECTED]>
'Date:
Mon 05/17/2004 at 15:22 (GMT)
------------------ Additional Follow-up Comments ----------------------------
Discussed with the svn developers for a bit, and I have some kind of plan together. As
I expected, they recommend DAV for scalability/stability.
There would be two root <Location> in apache conf, one under http for read only
(along with an online repository browser), and one under an https for read write.
Using svnparentpath we can have a single <Location> and all the project repositories
stored below a single directory.
The read-write control would be performed through a pre-commit hook I think, as it
would work with svn over ssh as well, and is probably needed considering the current
user accounts strategy
/**************************************************************************/
[task #118] Full Item Snapshot:
URL: <http://gna.org/task/?func=detailitem&item_id=118>
Project: Administration
Submitted by: Mathieu Roy
On: Mon 02/02/2004 at 00:58
Should Start On: Sun 02/01/2004 at 23:00
Should be Finished on: Tue 02/01/2005 at 23:00
Category: Services Functionalities
Priority: 1 - Later
Resolution: None
Assigned to: zerodeux
Percent Complete: 0%
Status: Open
Effort: 0.00
Summary: subversion support
Original Submission: Gna! should support subversion as alternative to arch.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Mon 05/17/2004 at 15:22 By: ttimo
Discussed with the svn developers for a bit, and I have some kind of plan together. As
I expected, they recommend DAV for scalability/stability.
There would be two root <Location> in apache conf, one under http for read only
(along with an online repository browser), and one under an https for read write.
Using svnparentpath we can have a single <Location> and all the project repositories
stored below a single directory.
The read-write control would be performed through a pre-commit hook I think, as it
would work with svn over ssh as well, and is probably needed considering the current
user accounts strategy
-------------------------------------------------------
Date: Thu 05/13/2004 at 12:07 By: zerodeux
Incidentally, someone from Xiph would be interested in a 'GNUish forge' with
subversion support :
http://mail.gnu.org/archive/html/savannah-dev/2004-05/msg00035.html
-------------------------------------------------------
Date: Wed 05/12/2004 at 19:25 By: ttimo
I would expect a good setup to be fairly low maintenance. There are a few things to
watch out for. If you consider Alioth, they had an appalling permissions policy which
was causing regular repository lockups.
For good scalability, the SVN developers recommend DAV transport (http/https) over
svnserve (ssh). I commonly use https for write access, SVN supports client
certificates but I never actually tried it. We can have ssh write access, but it will
involve a careful setup of permissions and umask.
-------------------------------------------------------
Date: Wed 05/12/2004 at 19:25 By: ttimo
I would expect a good setup to be fairly low maintenance. There are a few things to
watch out for. If you consider Alioth, they had an appalling permissions policy which
was causing regular repository lockups.
For good scalability, the SVN developers recommend DAV transport (http/https) over
svnserve (ssh). I commonly use https for write access, SVN supports client
certificates but I never actually tried it. We can have ssh write access, but it will
involve a careful setup of permissions and umask.
-------------------------------------------------------
Date: Wed 05/12/2004 at 18:21 By: yeupou
For testing, why not doing that on maggie indeed.
But I insist on the fact that maggie should at no cost run real public services.
Apart from that, I read that SVN was frequently broken wherever it is provided.
Installing it is one task, but maintaining is another. It would be nice if Timothee
can devote time to install it but it cannot work if he does not have time to also
maintain it on the long run.
-------------------------------------------------------
Date: Wed 05/12/2004 at 14:13 By: zerodeux
I'd propose to setup a Woody in a chroot'ed environment in our spare machine (ie.
Maggie), and have Timo install a SVN setup and try to write the Savane/SVN backend
(account creation, backup, etc).
If 1) it works, 2) we have a free IP to dedicate to this service (ports: http{s}, ssh,
?), 3) we can buy a dedicated machine, it could be a new official Savane service. I'm
not firm on #3, we'll see the machine load by then.
BTW, I've known Timo for a long time and trust him. He maintains ID Software's GPL'ed
level editor Gtk-Radiant as well as GNU/Linux ports of their (closed source, yes:))
games. He's been closely involved with SVN and its community for more than 2 years.
-------------------------------------------------------
Date: Wed 05/12/2004 at 09:29 By: ttimo
any progress on that one?
-------------------------------------------------------
Date: Thu 03/11/2004 at 10:40 By: ttimo
I have noticed that some other sourceforge forks have started providing SVN access. I
don't know which codebase gna uses exactly.
http://developer.berlios.de/forum/forum.php?forum_id=4718
Anyway, to answer (partly) your questions:
- storage: GtkRadiant repository (https://zerowing.idsoftware.com:666/) has 4320
revisions, and uses 1.1Gb.
It's a fairly large repository, as it was converted from a CVS repository, after 4
years of active developement, and is used to store binary media as well as source
code. SVN tends to be bigger though. Got an account of 120Mb -> 150Mb. Expect a size
increase around 20%.
The storage is berkeley db, so it's a single large random access file.
- backup:
SVN provides a hot-backup.py script which can be used and extended. It does a hotcopy
to duplicate the repository. I run it croned daily. Only doing hot-backup when the
repository changes.
- CPU load. for regular usage, backups, viewsvn .. hard to estimate. The same box ( P3
600Mhz ) we started GtkRadiant on CVS, we are still using with SVN. SVN generally
performs better for users for your server CPU cycles. Word on the street is that it's
less CPU intensive ( HD bound? ) + 'costs are proportional to change size, not data
size', which is not true for CVS.
- security / permissions etc.
the svnserve protocol doesn't offer much for permissions. It has an anonymous mode (no
write), and otherwise uses the permissions it is executed as. They plan to improve on
that, but the DAV way offers fine grained access already.
I can't say I'm a big fan of ssh for transport. It makes things fairly hard to setup
for windows users, which is my main problem with it. DAV over https, with client
certificates .. makes things about as secure as an ssh access anyway.
- web interfaces to repository:
ViewCVS: Requires the python bindings. I gave up using it on GtkRadiant, as it locks
me up (
http://sourceforge.net/tracker/index.php?func=detail&aid=895294&group_id=18760&atid=118760
)
SVN::Web: uses the python bindings. Is more bare-bones than ViewSVN, but a good
alternative. That's what I'm running now, but it has scalability issues on repos with
a lot of branches.
Chora: requires php, word is Chora as experimental SVN support.
The web interfaces will likely be causing most of the load.
- cvsreport-like:
There are contributed scripts in the SVN repository. I have one with web URLs which I
can contribute. It's much easier to write that stuff with SVN than it is with CVS.
-------------------------------------------------------
Date: Thu 03/11/2004 at 09:21 By: zerodeux
Let's try to detail a bit, we need :
- storage: what is the disk usage ratio between a CVS and SVN repository for the same
source tree ? What are bandwidth issues (lots of small scattered files ? heavily
random access ?)
- backup: svnadmin dump or hotcopy ? Need some insight (time, load, compression).
- CPU cycles: difficult to estimate. Right now we only have 90 projects and the CVS
server is lightly loaded (0.1 average). What is the load ratio between CVS and SVN for
the same source tree and usage ?
- init: need to hook a 'svnadmin create' in the group creation backend.
- security: preferred transport will be SSH, user & group rights should work as they
are now. Expecting WebDAV when there is a dedicated server for SVN.
- helpers: ViewCVS 1.0-cvs supports SVN. Needs a cvsreport-alike.
Comments/addition welcome.
-------------------------------------------------------
Date: Tue 02/10/2004 at 16:32 By: ttimo
do you have a roadmap at this point?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
ttimo --AT-- ttimo --DOT-- net |
For detailed info, follow this link:
<http://gna.org/task/?func=detailitem&item_id=118>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Project mailing list
[EMAIL PROTECTED]
http://mail.gna.org:8080/listinfo/project
