CVS alternative

Question

as the title says, I'm looking for an alternative to CVS. Basically, I'm unable to setup an a constantly on CVS server, and so far, the current setup my team uses is a shared directory.

With that in mind, I'm looking for something that has the features of version tracking, and file merging wherein I don't need to setup a constantly on server-of-sorts.

I was thinking, is there a CVS-like setup wherein the repository is just a shared network resource (folder, drive, etc.), and the users would connect to the repository, checkout their own local copies. Any changes the users would make would only exist on their local copies until they commit their changes, until which the changes would be pushed to the repository. If any conflicts are discovered, they are handled as if it were on CVS.

In addition, it would be an added bonus if it would work with Eclipse as a plugin, since that's what our team is using right now.

TIA

Answer 1

I agree with Keith Thompson's statement relative to staying with CVS, however, based on a review of DVCS done by actually trying git for two weeks, I cannot recommend git as a smooth replacement for seasoned cvs users looking for a smooth transition to DVCS with minimal retraining. Re-read that last sentence while paying particular attention to the qualifying clauses. I am not saying anything about git's ability to be a superior tool. And while personal experience is very often extremely subjective, git never "felt" right after some two weeks of determined use in order to learn it as a potential replacement for CVS. In the process of trying it out, I managed to bork things (think repository) up several times, and some things I never managed to figure out quickly.

When I ran up against the wall where git is unable to version directories, I looked at Mercurial and Bazaar as the most likely candidates to consider and found Mercurial had the same issue as git. In CVS I can easily add a directory with existing files without adding files inside it. git and Mercurial seem to act like this is a ridiculous thing to do. That the tool demands I cannot do what makes sense in a variety of use cases bothers me. As a result, I tried Bazaar, and it was amazing how I felt comfortable with it in minutes. After two weeks with git, I never did. My git repository converted to Bazaar in minutes and I was comfortable with using it in less than an hour.

I presently still use CVS and though I have committed to using Bazaar, I have experienced annoyances in edge cases where I use Bazaar in applications that are not usally issues in software development. Even so, as the guy who is most likely to train a group of CVS coworkers in an alternative VCS, I do firmly believe Bazaar will require the least retraining. It is almost trivial to use Bazaar in a workflow that closely correlates with CVS workflows. The guys I work with don't get their jollies by doing version control. They want something unobtrusive and easy to learn. I know that they will not maximize use of the VCS if they find the learning curve the least bit intimidating.

Not insignificant in the choosing of Bazaar is that it easily runs on Windows and integrates well with the MinGW MSYS environment. The integrated Windows installer is very suitable for an environment where one wants to minimize the effort of setting up workstations in a uniform manner - especially where some users will want command-line tools and others will want graphical tools.

Choice of a VCS is often heated by all sorts of biases. I started looking for a DVCS without being biased against any particular tool. I find git is inherently biased. It was developed with intense hatred of CVS (see the author's attitude toward CVS) and things CVS like $Id: $. Bazaar claims it tries to avoid biases against various workflows, and seems to avoid taking stands against things that developers come to appreciate in their particular use of other VCS. That's admittedly a subjective statement, but my experience with Bazaar seems to indicate it is true.

Bazaar does not provide all that I want it to. For example, I am not pleased that it does not support partial checkouts. This is remarkably easy to do in CVS. I am annoyed that Bazaar operations fail entirely over file-access issues with a single file in a group of files being acted on, but this should generally not happen in typical software development use cases. What I'm trying to say is I am not blindly enamored by Bazaar, but I still believe it to be the easiest tool to transition to away from CVS in a small engineering department.

As a footnote, many years ago joined an SVN open-source development team with an express goal of getting comfortable with a CVS-like, improved VCS. I have worked with SVN a lot and have even set up partial checkouts, etc, but I disagree that SVN is "CVS done right". After years of use, I cannot responsibly select SVN as a successor to CVS in my organization for a number of reasons. It trades one set of issues for another. While that is true for almost any tool, the benefits of SVN do not seem to outweigh the issues when considering the costs of making the transition.

Answer 2

I don't see any strong reason you couldn't continue using CVS. If you have a "shared network resource" that's visible as if it were an ordinary file system (users can read, create, and write files), you can just put your CVS repository there and have your users set $CVSROOT appropriately. Or you can set up a Linux or other Unix-like system with ssh access; CVS works fine over ssh.

If you're able to have a shared directory, you can use CVS.

There are plenty of reasons to prefer other systems over CVS (personally, I've become a big fan of Git), but it doesn't sound like you need to switch right away.

My advice: Consider switching from CVS to Git, but it's not urgent.

A quick Google search indicates that Eclipse/CVS integration shouldn't be a problem.

Answer 3

SVN had the slogan "CVS done right", so it will be quite easy to get SVN phylosophy after using CVS.

However, some people say "there is no way to do CVS right" and would recommend using Git. Git is much more advanced and offers cool features like distributed version control and lightweight branching, but the learning process is more difficult.

P.S. I use Git and i'm happy with it!

Answer 4

Commonly used and well supported version control systems include Git, SVN, and Mercurial. Of those, I have used SVN myself and run a few repos, but people tend to say that Git and Mercurial are easier to use.

You can get a SVN plugin for eclipse, called subclipse.

The others probably have them too but I don't know.

Answer 5

Git is your best friend. Distributed, robust and incredibly fast! For your Eclipse integration try EGit