On 2024-10-25 22:48, Richard Stallman wrote:
There is no need to change how we handle certain directoriess just
because a newer feature exists.  Does use of CVS for them cause a
concrete problem?

Sure it does. It's already a pain to learn and set up Git. Now I have to learn and set up another version-control system?

For an experienced developer like me it means I need to reinstall CVS and copy my CVS configuration from the last time I used it (which was a while ago on some other host - now where was that?). When committing changes, CVS is significantly slower than Git. And when CVS fails it is significantly harder for me to debug what went wrong. Although this stuff may sound trivial, for small tasks (the typical case here) CVS's extra burden is great enough that I often put off the tasks indefinitely. This partly explains why GNU web manuals are so often out of date.

For new developers, CVS is a large enough obstacle that they don't bother. It feels to them like insisting apps be written in Fortran. Sure, Fortran *works* - but hardly anybody wants to waste even a tiny fraction of their life learning it.

If you find CVS convenient for maintaining the GNU coding standards, that's great; keep using it. I get it. I still use RCS - which is even simpler and easier and older than CVS! - for some old stuff I maintain, because I used RCS for it back before Git or CVS existed and I haven't taken the trouble to migrate. But I don't ask other people use RCS for their projects.

Git would be much better for maintaining GNU web pages for the software that I help maintain. I don't know why I must keep using CVS for this maintenance, which is done only by people who use Git daily and obviously would prefer Git.

Reply via email to