VersionControlSystems < Know

---+ Brainstorming for a Version Control System for use with the Linux Kernel, U-Boot etc.

---++ Git:

   PRO: Used by the linux kernel.  Since that is the biggie and users of u-boot will (inevitably) use git, it makes sense to use git for u-boot
   PRO: Fast and stays fast (scales well)
   CON: Immature (but maturing fast under the extreme pressure of kernel development)
   CON: Currently not supported by a CVS -> git import tool (but see http://www.cobite.com/cvsps/ and discussion in http://kerneltrap.org/node/5014)

---++ Monotone:

   CON: importing the U-Boot CVS repository using the =cvs_import= command is slow
     (32 minutes)
   CON: initial import of U-Boot source tree using =tailor= fails
   CON: initial import of Linux kernel tree using =monotone cvs_import= fails (monotone bug)

---++ Darcs:

   <strong>CON</strong>: Quote: "Darcs is not intended to maintain a history of versions,
     although it is possible to kludge together such a revision history,
     either by making each new patch dependent on all previous patches,
     or by tagging regularly." %BR%
     This might result in QA issues, especially when some sort of certification is needed.
   PRO: [Zachary P. Landau, 26 May 2005]: %BR%
     excellent for cherry picking merges
   CON: [Zachary P. Landau, 26 May 2005]: %BR%
     speed issues ... especially the case with large trees (like the Linux kernel) %BR%
     *Some Tests using the linuxppc_2_4_devel source tree:* %BR%
     <verbatim>
-> time darcs whatsnew
No changes!

real    2m55.819s
user    0m1.820s
sys     0m2.676s
     </verbatim>
   CON: =cvs2darcs= does not work - importing the U-Boot CVS repository results in an empty Darcs repository;
     not really critical as importing the CVS tree using =tailor= works just fine and pretty fast
    (1 minute 12 seconds)
   CON: written in Haskell; non-trivial to build completely from sources only;
     no local know-how in case of problems or if extensions needed/wanted

-- Main.WolfgangDenk - 30 May 2005