Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> A good argument for upgrading any cvs servers you control. > > Unfortunately, it's the clients that you would need to upgrade - it's the > GPLed 'cvs' client which pushes the load to the cvs server. And the client > that has this behaviour fixed is not free software. > >> If no one objects to dropping CVS support, I'll be happy to switch now. > > Yes, please. Doing this will help > - people with a modem or DSL connection, > - doing renames, > - keeping the ChangeLog a single piece, > - maintaining forked copies of gnulib, > - determining the checkout identification (requested by Eric a few days > ago). > >> But that would require a certain amount of hand-holding and updating >> FAQ/etc. telling people how to use git enough to "pull" (aka update), >> and how to prepare patches properly (which means explaining the basics of >> git topic branches), etc. > > Yes, and I'm willing to help on it. Find attached already the doc patches. > It's a time well invested, since the design of cvs is based on network/disk > tradeoffs that are not correct any more with today's hardware. > >> The desire to retain CVS access (e.g., for Karl :-), and the fact that it >> will have to be via git-cvsserver to provide at least read-only pserver >> access, means I'll have to exercise a certain amount of due diligence, >> too. I'll have to set up something separate, test it, and then, once >> confident everything works the way we want, choose a nonstandard port >> on sv.gnu.org for use as the git-pserver port and set it up there. >> (the pserver port is already in use, of course). > > Yes, please!! I can help updating the docs afterwards.
Thanks for volunteering. Let's give people a few days to speak up. If we can agree to switch to git, I'll do my part. I hope you can be patient for a little while longer. I'm going to be on a weird schedule for the next 3 weeks, with less frequent net access than normal.
