-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bob Friesenhahn on 9/19/2007 9:52 PM: > Very interesting. If various projects flee from CVS to some other > version control system then I hope that the projects I am involved with > flee to the same system rather than many different systems. Like most > people here, my hands are already full with development of projects and > learning new version control systems loses valuable time. One of the benefits of git is that it comes with git-cvsserver. In other words, even with git as the repository, you can still use your CVS client to access the repository. Yes, it's less efficient, but it works, and the repository is still accessible on platforms where git has not been ported yet. git-cvsserver can even support write access, although gnulib chose to use the cvsserver in read-only mode (to commit to gnulib, you now have to use git). Also, git has a growing user base, with some good documentation on learning common commands for those used to CVS-based workflows. Again, I'm not turning CVS read access off, rather, I have a goal to phase out CVS write access. > > I have looked at Subversion and find its installation to be rather > unwieldly, requiring many additional packages to be installed of > particular versions. Subversion seems to use a rather exotic > implementation rather than a fairly simple one like CVS. It seems that > GIT has the advantage in this regard. I tried 'arch' but it did not > compile on my machine at the time so I never looked back. One of my criteria for git was having it work on cygwin; a year ago, that was not the case. Yes, git is not yet as portable as what autoconf targets, but on the other hand, you don't need git to use autoconf; you only need it if you are contributing autoconf patches. And in case you really can't get git to work, you can still generate patches using the CVS interface, mail them to this list, and rely on others with git access to do the actual commit. Ultimately, I like distributed version control better than single-access, which already knocks a number of systems out of the running (for example, CVS, subversion, monotone) - there is just too much benefit for having the potential of the entire history on your local machine, with no network traffic involved to search the history. It's a new mindset, and the git documentation admits this, and even offers suggestions on how to use git in a manner consistent with the old CVS mindset of a central repository [it is likely that most GNU projects on savannah (autoconf included) will stick with the CVS mindset of a master repository for some time to come]. Between the remaining vcs options, one of the reasons the GNU development has seemed to switch to git, rather than mercurial or bzr, is the responsiveness of the git development team, and the fact that support has been added on savannah.gnu.org to host git projects. - -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@xxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8fU084KuGfSFAYARAjtbAJ4ufJnXr3RgGv5EhEMCTouScveZlgCggJI3 73p46YE7XI9TMW1RE/4ZUn0= =cd+z -----END PGP SIGNATURE----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
