# Opinions on version control systems



## fonz (Mar 28, 2013)

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.


----------



## jrm@ (Mar 28, 2013)

I like devel/fossil.

http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
http://stackoverflow.com/questions/156322/what-do-people-think-of-the-fossil-dvcs


----------



## kpa (Mar 28, 2013)

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.


----------



## jrm@ (Mar 28, 2013)

In case you haven't seen this comparison of revision control software, here is a link.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software


----------



## Anonymous (Mar 28, 2013)

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.


----------



## fonz (Mar 28, 2013)

jrm said:
			
		

> In case you haven't seen this comparison of revision control software, here is a link.
> 
> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software


Thanks, but I had actually noticed. However, just cold specs aside, I'm interested in hearing about user experiences too. Particularly @rolfheinrich does a pretty good job of explaining why he uses what he uses.


----------



## torr_from_fallout2 (Apr 2, 2013)

*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


----------



## fluca1978 (Apr 4, 2013)

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!


----------



## KdeBruin (Apr 8, 2013)

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.


----------



## fluca1978 (Apr 8, 2013)

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.



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.


----------



## ta0kira (Apr 17, 2013)

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


----------



## expl (Apr 17, 2013)

ta0kira said:
			
		

> 1) some jerk adds a 100MB file and then removes it, giving everyone else a permanent 100MB of extra baggage



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



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


----------



## fluca1978 (Apr 18, 2013)

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.



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.



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.


----------



## kpa (Apr 18, 2013)

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.


----------



## expl (Apr 18, 2013)

fluca1978 said:
			
		

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



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.



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.


----------



## ta0kira (Apr 18, 2013)

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.


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


----------



## kpa (Apr 18, 2013)

You can clone the whole FreeBSD src GIT repo from https://github.com/freebsd/freebsd.git. That's the whole repository with every single commit from the beginning of time. It is big.


----------



## fluca1978 (Apr 19, 2013)

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.



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.


----------



## expl (Apr 19, 2013)

fluca1978 said:
			
		

> I believe the schema used to fragment repo/history strongly depends on points of view and developers you are working with.



Well that goes for virtually everything in software engineering not just version control routines.


----------



## jrm@ (May 27, 2013)

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.



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.


----------



## kpa (May 27, 2013)

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.


----------



## Carpetsmoker (May 28, 2013)

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.


----------



## fluca1978 (May 30, 2013)

Carpetsmoker said:
			
		

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



Could you provide an example of an operation that has a bad command in Git compared to the same in Mercurial?


----------

