On 2006-01-12, Erik Wikström <[EMAIL PROTECTED]> wrote: > I'd say that if there is a move then it will be to a decentralized VCS > and with some luck it will include an efficient checkout in the package.
Hm, I went for Mercurial and I'll never look back (the same regards to the Linux kernel tree on my Linux box and would regard to FBSD source tree on my FBSD box if someone would ever care to set up a Mercurial mirror for it). Yes, it will be never included in the base, because it's in Python which is not feasible for the base. But honestly, is it worth to care about? You can either: * pkg_add python, bootstrap pkgsrc, insert Corecode's unofficial Mercurial installation ruleset, install Mercurial; * bootstrap pkgsrc, compile python, insert Corecode's unofficial Mercurial installation ruleset, install Mercurial; * pkg_add python, install Mercurial by hand; .... It's not a big fuss, and "insert Corecode's unofficial Mercurial installation ruleset" stage will go away as soon as Mercurial will get into pkgsrc. Once it's done, the source can be checked out and Mercurial provides fast updates, superb offline history browsing with changeset based view and it eliminates the need of retrospective "src-051113{,.tar.{gz,bz2}}" style source tree backups as it features fast forwards/rewinds of the source tree and cheap (hard link based) clones for the case when one needs two snapshots simultaneously. So as an end user, I massively ignore what the main repo is stored in as long as the Mercurial service is in place; the other POV is that of the maintainers of the main repo -- I'm sure they will be able to figure out what's the optimal for their purpose. (Oh yes, another POV is that of mirrors, and yet another is that of the ones with a commit bit -- but my [naive?] idea is that the VCS backend makes a difference mainly for repo maintainers and end users [who do source based updates]). Just my 2 cents. Csaba