Re: Public Nmap SVN Repository

[Andreas Ericsson <ae () op5 se>]

Fyodor wrote:
> Don't you guys think a public Subversion repository for Nmap would be
> useful?

Yes, oh yes. I've been looking for one for ages (I think I even posted 
about it a while ago). I'll import it to git as soon as it comes out and 
mirror it somewhere for those of us who prefer a distributed repository 
model, which I'll shamelessly plug here throughout the rest of the mail.

>  I've been reticent in the past due to qualms about SVN
> security.  I'm still nervous about it, but at least the Subversion
> project has gone a couple years since their last serious security
> holes.  I'm also getting better at locking down services with SELinux.
> So I think the benefits are worth the risk.  Here are my initial
> implementation ideas:
>
> * I'll use svnserve (svn:// format) rather than the Apache2 DAV stuff
>   (http:// repository).

git-daemon fairly rocks for this. It's been running on kernel.org the 
past 9 months. The backside is that it only allows read-only access so 
you need to have ssh set up for when you want to publish your changes.

> * Everyone will have read access to the Nmap/Nsock/Nbase trunks
>
> * Nmap developers working on cool experimental stuff (Like Diman,
>   Doug, Marek, etc.) can have their own branches, if they want 'em.
>   That way they can implement cool stuff, and everyone can download
>   and test it easily, but it won't destabilize the main Nmap trunk
>   until it is ready for merging.  For example, the raw packet NSE
>   support might be a great candidate for its own branch.

With a distributed repo model, *everyone* will have as many branches as 
they like (locally ofcourse) and you can get patches by either pulling 
from their repos, them mailing you patches (generated by the scm) or by 
them pushing to a different repo on the same server which you can then 
pull from.

> * A mailing list (nmap-commits or something) will be set up, to which
>   commit notifications (with diffs inline) will be sent, through a
>   post-commit hook.

Humm... Usually lots and lots of mails in times of heavy development. 
Perhaps you should consider sending only commit-messages whenever you 
tag a release?

> Does anyone know any good reasons for using mod_dav_svn (Apache)
> rather than my current plan of svnserve?

With mod_dav_svn you can (I think) enable write-access over http. I'm 
not sure that's a desirably feature, but it's possible anyways.

> A quick search finds this script for sending commit emails:
> http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/commit-email.pl.in
> Can you guys recommend this, or do you know anything better?

The default email-sending scripts shipped with git are better than any 
cvs or svn counterpart I've ever seen. I wrote that particular one in 
git though, so I'm probably biased (in git it's called "update-hook" btw).

> How important do you guys think it is to be able to browse the
> repository with a web browser, link to revisions, etc. using something
> like ViewCVS or Trac?  I don't presently plan to implement this, but I
> probably can if there is demand.  If you want it, what software do you
> recommend?

http://git.kernel.org/git
http://repo.or.cz/

Incidentally, gitweb has rss feeds which someone wished for in another 
email, as well as the ability to generate snapshot tarballs based on any 
given revision.


> Is there anything else you think is important to consider for a new
> Nmap public source repository?

Use a distributed scm. Centralized ones give maintenance headache when 
old developers drop out and new ones hop in. Distributed scm's also 
gives all contributors the power of a version control tool for when 
they're just toying with new features and things like that.

I can help you get everything rolling with git if you want. Otherwise 
I'll just import it and keep a separate mirror-site.

-- 
Andreas Ericsson                   andreas.ericsson () op5 se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org