Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Nmap and SVN Externals
From: David Fifield <david () bamsoftware com>
Date: Tue, 3 May 2011 02:18:13 -0700

On Fri, Apr 29, 2011 at 05:02:15PM -0700, Fyodor wrote:
So those are the problems and benefits of externals as they are used
now.  Maybe someone can pipe up with other pros and cons they have
seen with the way Nmap svn is organized.  But there are other options
we could do instead.  The ones which come to mind immediately are:

1) We could svn mv /nsock, /ncat, /nping, and the like all under
   /nmap.  This would "solve" the problem of dealing with externals
   for Nmap, but I think it is a bit worse of an organizational
   structure.  And problems like Ncat wouldn't be helped.  They'd just
   have to change their svn:externals /nmap/nsock and /nmap/nbase
   rather than /nsock and /nbase.  Still the vast majority of our work
   is Nmap-related, so this technique is worth considering.

Number 1 is what I think should happen. I don't think it's a poor

2) I thought that if we got ride of the svn:externals and had users
   manually checkout nmap and then cd there and checkout /nsock,
   /nbase, and the like underneath, that would work better.  But upon
   further testing, that works worse than the externals approach.  It
   means you have to specify the "external" directories even for svn
   update, and svn status doesn't tell you about changes in the
   subdirs.  So scratch that.

3) Switch to another revision control system, such as git.  I don't
   think git can handle per-user read access control for the private
   parts of the repository (I have system configuration files and all
   sorts of other crap there), but we could potentially split off the
   public Nmap stuff into its own repository.  Of course switching to
   a new RCS would be a major pain.

In git we would have separate repositories for different projects, not
everything in one big repository like we have now. For example we could
have git://git.nmap.org/nmap.git and git://git.nmap.org/nmap-private-dev.git,
with different access controls. See https://gitweb.torproject.org/ for
an example of lots of repositories being served by the same server.

David Fifield
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]