Ask HN: Is CVS (Concurrent Versions System) Dead? Long Live CVS
We're mostly a monorepo shop and cvs is serving us well, given the scale and branches. Git wasn't there so I guess the founding members went with cvs. Till now there was no need felt even though attempts were made.
The problem is with modern tools and IDEs having zero support. The love for Git went extreme levels it seems. I felt to show some love for cvs and decide to build a "Git For Visual Studio" but for "cvs".
Microsoft standardized SCC interface for IDEs (SCCI provider) so I felt my job as easy and visualized replacing git in VS with cvs. To my surprise, it looks like MS has abandoned MSSCCI support and following the docs didn't help my POC.
Once I was able to get it up and running, I found it doesn't support much of the functionality like history, blame. Just basics like 'Add Project to Source Control', 'Checkout', 'Checkin'. I thought plugging in the interface will give me the same diff and history interface. Why would MS develop such a useless interface for such an important piece of soft.
After spending a week of time, I realized there is no way than to write an extension (vsix) from scratch with all the support which I felt as duplicate, so abandoned my efforts.
I hope I won't cross my path again with cvs \m/ In 2002 I wrote a Lisp program called Meta-CVS. It uses CVS to store files in a certain format, which allows versioning of the directory structure, symbolic links and permissions. As well, it has a "mcvs grab" command for importing snapshots of external code such that renames are identified. Plus it has merge automation with tracking. Plus interactive workflow when creating a repo, for identifying binary files and whatnot. The support for renaming in Meta-CVS blows git out of the water (since that basically doesn't have any). People continuing with CVS crazy not to be at least using Meta-CVS to make their lives easier. I used Meta-CVS once to clean up a mess. In the company I was working on, my friend, a configuration manager, came to me with a problem: merging some large amount of Java cruft from a branch where the developers did various renames. Not just A to B renames, but cyclic renames A.java renamed to B.java, while B.java renamed to C.java, while C.java again renamed to A! (Would you believe it.) This had to be merged to the trunk. I whipped out Meta-CVS for the task. "mcvs grab" easily identified the rotating renames and merged the content, which we were then able to check into the VC actually being used (might have been SVN). wow.. i know what you are talking. Is meta-cvs available somewhere? Why yes; the Meta-CVS page lives on: https://www.kylheku.com/~kaz/mcvs.html Let me warn you in advance that Meta-CVS isn't just a client you can use over CVS repos to get all those nice things. It uses CVS repos to store its own format. All the files are given UUID-like hexadecimal names, stored as a flat directory. The mcvs program maps checks that out in a MCVS/ subdirectory. (So there is a MCVS/CVS directory under that where the ,v files are.) The MCVS/MAP file is a Lisp data structure which maps the UUID names to paths. The program builds and maintains the working tree according the MAP file. Meta-CVS requires CLISP. Hopefully now just "apt install clisp" nowadays, and similar. When I developed Meta-CVS as my first nontrivial Lisp project, I soon learned about people who will try to "strongly advise" you to write in Perl or Python: "Another downside to Meta-CVS is that it is written in Common LISP. Granted, Common LISP is a very powerful and flexible language. However, it is not very common (pardon the pun) on UNIX and other systems, and few people could be expected to install a client if they need to install it first. If Meta-CVS' author wishes to make it more popular, I strongly advise him to re-implement it in C, Perl, Python or something more standard." http://better-scm.shlomifish.org/docs/nice_trys.html I don't think any technology ever really "dies" CVS included. There are shops using perforce (a proprietary centralized version control system) as their SCM. It is true CVS is less popular in open source, but I think that has more to do with code hosting providers either not supporting it or dropping support (BitBucket dropped support some years back). OpenBSD is a huge CVS repo and has been working on got (sic) as a potential alternative. I think CVS might not be a perfect fit for OSS development[0]. For the rest, it is great. But look like big players moved to git to please the opensource community. >Why are people so obsessed with getting the OpenBSD developers to move from CVS? If it works for them and do what they need there's no need to move.