andrew,   
      
   > 16 Dec 11 19:45, you wrote to all:   
   >> I've been thinking about migrating the existing MakeNL CVS   
   >> repository to something like SVN. For multiple reasons, including:   
      
   > I migrated all the ARTWARE (timEd, NetMgr, WIMM) repos to SVN recently.    
   > It was pretty painless. I don't think anyone is actually working on      
   > any of that stuff any more but I had other personal projects on my      
   > CVS server that I wanted to migrate to SVN so it made sense to move     
   > everything across.   
      
      I've started the (long!) process of doing similar with those projects I   
   have admin responsibility for.  For the SourceForge related projects, that   
   their new SF project software doesn't support CVS only affected the timing, as   
   I would do the migration at some point in any case.   
      
      
   > I highly recommend cvs2svn, so the old CVS commit history gets imported    
   > into the new SVN repo:   
   > http://cvs2svn.tigris.org/   
      
      I don't recall off hand what I've used before;  it may have been that one,   
   or it may have been one of the others... It's certainly important to get the   
   existing history over to the new repository, so I'll be using that or   
   something like it.  (SF has a procedure posted about how to do such a   
   migration but I don't know what it uses...)   
      
      
   >> 3) I know not much work is being done on MakeNL these days but I'd   
   >> like it to stay possible and I think, because of the issues that CVS   
   >> has, that it be best to migrate it away from CVS.   
      
   > Yeah, I'd like to see the repo continue. You never know who might want to   
   > contribute something.   
      
      Exactly.  Or something found in the course of recompiling it for newer   
   systems.  It's much easier to do things like that if the code is publically   
   available in a somewhat modern repository.   
      If I can figure a way, I'll see if I can get some of the older code imported   
   as well.  Source archives are easily imported into a GIT repository & the   
   commits can even reflect the correct dates for the files. Useful for getting   
   history into a code repository.  Or, since the new SF software supports   
   subprojects;  if those can have separate & different code repositories (I   
   understand that's so but I'm not for sure...), then I'll just have a separate   
   project for the debian packaging, which is already in a GIT repository.   
      
      
      
   Jame   
      
      
      
   --- BBBS/LiI v4.01 Flag   
    * Origin: BBBS Info (1:120/546)