Opinions on version control systems

F

fonz

So far I have always used CVS for my personal projects, but FreeBSD's recent switch to Subversion is perhaps a good incentive to reevaluate, or at least to see what else is out there. So, which do you prefer and why: CVS, Bazaar, SVN, Git, Mercurial, or perhaps something completely different? In case it matters, I do have a little shopping list:
  • must support both plaintext (anonymous, checkout only) and encrypted (SSH tunnel is fine) connections;
  • repositories probably won't get large, but there are several different projects and some of them share code;
  • I don't foresee having any need for very advanced branching/merging stuff;
  • most data is code, but there are some binary files (e.g. images) as well;
  • fine-grained access control would be nice;
  • preferably no more difficult to setup and maintain than CVS;
  • widely supported, i.e. not too exotic;
  • preferably something that's either easy to learn or uses syntax similar to CVS;
  • free and open source, of course.
 
I use devel/git for my own stuff. I like the "everything is local" methodology of it. Overall I find it simpler and less crude than CVS/RCS because the dirty details of the actual storage are hidden properly without sacrificing important features. It takes a bit getting used to GIT's concept of a commit, it's not quite the same as in other VCS systems.
 
I was also a former mostly happy CVS user, and I switched to SVN, mainly because I do all my coding using Xcode on Mac OS X, and CVS support has been abandoned in Xcode 4.x, which got built-in support for SVN and Git.

Besides this, my requirement list was very similar to yours, and with SVN, I almost immediately felt at home.

Before, I was forced to use Mercurial for a certain project, and I have to admit that I never exactly understood all the magic behind pulling/pushing/merging/branching, and pulling in code from the main branch in order to merge it into my working copy and pushing all back to my clone in the repository, never worked without any pain for me.

IMHO, the worst thing was that every member of the development group was coding on his own clone, and from time to time the changes were pulled into the main line OR NOT. I am a physical chemist, and we call that entropy generation, i.e. dissipation of working energy into hot air. So for me the concept of distributed VCS looked nice on the paper, but in practice it turned into an unmanageable mess.

So, I even didn't consider Git, and simply switched to SVN. Now, I am a mostly happy SVN user.

Some notes:

- The SVN-Manual is great.

- In CVS, I had my projects in one repository.
- In SVN, I have one repository for each of my projects (fine grained access rights)

- For encrypted access I built SVN with the SASL2 option, so there is no need to do SVN over https.
 
Git

I was in a similar situation as you. I am developing code on Xcode and wanted a freebsd repository box. It was decision for either subversion vs Git for me and ultimately I choose Git because of its simplicity. But the reality is both are good choices.

Judging by your criteria, the only negative strike Git has against it is that it doesn't handle binaries very well. Correct me if I'm wrong, but git just deletes the old binary and replaces it with the new one - subversion works better in this regard as it stores the previous binary file.

If you want to build a secure freebsd Git repository, follow the instructions here:
http://forums.freebsd.org/showthread.php?t=34878
 
I've worked for years using git, mercurial, cvs, svn. I'm not a guru in any of them though.
My favourite is git, and it is the one I use for all my private stuff and for some job stuff. I prefer SVN other CVS because I found it to be more linear and simple to use (e.g., revision numbers). Mercurial sounds to me as the SVN approach to distributed rcs, but I don't like the fact that a lot of feature have to be enabled via plugins, I tend to want a complete system and for that git is the best to me.
One drawback of git I found is that repository metadata tends to be quite big, and therefore a garbage collection has to be done. On the other hand, destroying a repository metadata is as simple as a rm, while with CVS for instance you have to do a find and remove. But this is of course not a selling point!
 
Using devel/git at home to manage several websites with development done on several machines. At work we use devel/csv but are gradually switching to devel/mercurial for new projects.

The main advantage from both git and mercurial is in my opinion the fact that I can work on new features and check any changes in locally until some dependent part is properly upgraded. After this I can push all my changes upstream with a complete commit history.

When using cvs you have a lot of changed files for many different issues but these cannot be committed until the release of the dependent part is done. The result is that you loose a lot of edit/commit history as all is committed in one big batch.
 
KdeBruin said:
When using cvs you have a lot of changed files for many different issues but these cannot be committed until the release of the dependent part is done. The result is that you loose a lot of edit/commit history as all is committed in one big batch.
Click to expand...

That is why I believe that a distributed tool is better than a centralized one. Moreover, while it probably does not happen to real programmers, I found myself often doing a commit and immediatly after changing the same because of some regression was not tested enough. With Mercurial or Git or alike it is possible to change the history "merging" the commits, while with CVS or SVN I have to admit I was wrong and make two different commits.

I have however to admit that, as pointed out by @rolfheinrich, using a centralized system surely avoid effort duplication, but at least if the team using the tool has a clear understanding and systematic usage of the tool itself. After all, there are a lot of great projects still managed on CVS.
 
Last edited by a moderator:
I've really only used git and subversion. I've been using subversion for my personal projects for quite a while and I've had to use git at work.

My main complaint about git is that you can't check out a subdirectory. You can't even check out the current revision; you need to have a clone of the whole respository. This is fine unless 1) some jerk adds a 100MB file and then removes it, giving everyone else a permanent 100MB of extra baggage, 2) the part you need to work on is only a small fraction of the repo. When I experienced the former, well, I was the jerk in question (someone wanted a MySQL dump in the repo and I added the wrong one.) When I experienced the latter, the repo was ~10GB and the part I needed to work on was only about 0.1% of that. Granted, both are results of mismanagement, but repos never get smaller, and if everyone has a copy then the growth rate is multiplied by the number of people using it.

The only problem I've had with subversion was related to working from a case-sensitive HFS+ partition in Linux. $ svn diff [i]file[/i], among others that I can't remember, didn't work at all because svn saw everything as a directory. I was still able to perform all of the fundamental operations, but to get a diff of a specific file I had to create a script to pull out the lines pertaining to that file from the diff of the entire working directory.

Other than those few things, both work equally well for me.

Kevin Barry
 
ta0kira said:
1) some jerk adds a 100MB file and then removes it, giving everyone else a permanent 100MB of extra baggage
Click to expand...

Can be fixed by a hard commit reset, will make it look like the commit never happened. Happened to me couple of times, easy fix.

ta0kira said:
2) the part you need to work on is only a small fraction of the repo
Click to expand...

This issue can be avoided altogether by fragmenting big project to multiple repos, to at least separate binary files from source code.
 
expl said:
Can be fixed by a hard commit reset, will make it look like the commit never happened. Happened to me couple of times, easy fix.
Click to expand...

Unless the commit has been made public, since public history cannot be modified easily.


expl said:
This issue can be avoided altogether by fragmenting big project to multiple repos, to at least separate binary files from source code.
Click to expand...

True, but my experience is the opposite: usually developers tend to make a big repo with several projects into it, in order to let you download all the stuff you need at once and work on small part of it. The problem with repo fragmentation is that history becomes heterogeneous. However, I agree, repositories should be splitted as much as possible.
 
In GIT everything is local so what is a "public" commit? :e

When you fetch and merge changes from a remote repository you have a full control of what gets merged to your local repo. You can even undo merges that you find out later that you want to revert.
 
fluca1978 said:
Unless the commit has been made public, since public history cannot be modified easily.
Click to expand...

Well [cmd=]git reset --hard ...[/cmd] will modify the history of the branch and then you can just push it to reset 'public' one.

fluca1978 said:
True, but my experience is the opposite: usually developers tend to make a big repo with several projects into it, in order to let you download all the stuff you need at once and work on small part of it. The problem with repo fragmentation is that history becomes heterogeneous. However, I agree, repositories should be splitted as much as possible.
Click to expand...

At our company we fragment repositories heavily, not for performance/space, but for security and access control since access control per branch is non existant due to design of the GIT engine.
 
fluca1978 said:
True, but my experience is the opposite: usually developers tend to make a big repo with several projects into it, in order to let you download all the stuff you need at once and work on small part of it. The problem with repo fragmentation is that history becomes heterogeneous. However, I agree, repositories should be splitted as much as possible.
Click to expand...
It also comes down to how the projects are managed at a higher level. For example, svn://svn.freebsd.org/base has 249624 revisions over the last 20 years, and it would be unreasonable to require that every developer have a clone of that whole thing. I can't imagine how much space that takes up (maybe a developer can du the repo for us?). At the same time, however, FreeBSD is managed by a specific group of people, and managing the permissions of hundreds of repos would be more unrealistic than forcing everyone to clone the repo. Also, the hierarchy of the FreeBSD source can't be clearly divided into smaller parts, e.g. contrib contains sources but the corresponding Makefiles are in another tree. In that case subversion is more appropriate than git because the former allows you to check out a single version of any subdirectory. However, there are plenty of cases where git would be more appropriate, such as a single application that isn't centrally controlled.

Kevin Barry
 
expl said:
Well [cmd=]git reset --hard ...[/cmd] will modify the history of the branch and then you can just push it to reset 'public' one.
Click to expand...

Yes, but in the meantime you have spread your changes to everyone has pulled the repo before your reset.

By the way, in these days also PC-BSD has moved to Git, and they were not transferring the whole history to avoid bloating the repo. I believe the schema used to fragment repo/history strongly depends on points of view and developers you are working with.
 
fluca1978 said:
I believe the schema used to fragment repo/history strongly depends on points of view and developers you are working with.
Click to expand...

Well that goes for virtually everything in software engineering not just version control routines.
 
rolfheinrich said:
IMHO, the worst thing was that every member of the development group was coding on his own clone, and from time to time the changes were pulled into the main line OR NOT. I am a physical chemist, and we call that entropy generation, i.e. dissipation of working energy into hot air. So for me the concept of distributed VCS looked nice on the paper, but in practice it turned into an unmanageable mess.
Click to expand...

By default devel/fossil (sort of) works like devel/subversion in that it synchronizes to a central repository, but it also has the advantages of distributed source control management. See the section 4.0 Workflow in this Fossil Concepts document.
 
I think it's not a fair criticism. The version control systems or other tools used should not dictate the development practices, when to commit, what to commit, which repository is seen as the main central repo etc. Those questions have to be answered on the project management level. If the project turns into an unmanageable mess because everyone was just coding on their own copies the failure was then clearly in the management of the project that couldn't keep up with what was happening.
 
The git commandline interface sucks. Like a heroin-addicted hooker who hasn't had a shot in a week and just got her first customer.

For Windows, there's tortoiseGIT, which is based on tortoiseSVN ('nuff said 'bout that I would say, tortoiseSVN sucks balls, and so does tortoiseGIT, although I must admit it sucks slightly less).

Other than this, I guess the technical part of git is okay, it's just the interface that's crappy ...

mercurial does pretty much the same as git, except with a significantly better interface (both commandline and graphical, note that the graphical tortoisehg is *NOT* based on tortoiseSVN).

I've also used subversion, and it's sort of okay, but I much prefer mercurial because it's a distributed system.
 
Carpetsmoker said:
Other than this, I guess the technical part of Git is okay, it's just the interface that's crappy ...
Click to expand...

Could you provide an example of an operation that has a bad command in Git compared to the same in Mercurial?
 
You must log in or register to reply here.
Back
Top