Version Control

[SiliconWizard]

This poll is not meant to trigger flame wars, so please refrain . Just to get an idea of the "popularity" of different VCS, tilted towards EE/embedded software development.

You can mention the one you use if you chose "other". You can also mention your reason for prefering a particular one if there is any (as long as there is no useless flaming.)

[SiliconWizard]

Dare I say Windows file history and Apple time machine?

Why not, if that fits your needs.

I've actually used a "backup" kind of version control for years before switching to a conventional VCS (first one was SVN). There was a "changelog" file maintained for each version (which I think is a good habit anyway, and I've kept it), including the "bug fix number" (third number in the traditional versioning system).  We also used that in small teams, and the merging (when several people had worked on the same piece of code) was done "manually" during interactive merge sessions with all developers involved. That worked quite well and avoided a lot of the frustration you can get when fully relying on automatic merge, or manual merge that each one tends to do on their side...

Sure, you'd say that this method wouldn't scale up well for bigger teams.

Then I moved on to SVN (which was a company choice).

I've also used CVS and git, but my preferred system now (for a few years) is Mercurial. It's simple enough to fully grasp in a short time, it won't let shoot yourself in the foot like git can sometimes. It's less popular than git though, so obviously I've gotten occasional remarks that I should switch to git (even if the rationale is never clear except that it's popular), but I've found it works quite well, from individual  developers to medium-sized teams.

[Jeroen3]

SVN is on maintenance, only bugfixes and minor performance tweaks.
Mercurial is dying.
CVS, is that still around?.

We've made it into a git monopoly...

[RoGeorge]

My favorite is "Save as".   

[PlainName]

SVN is on maintenance, only bugfixes and minor performance tweaks.

I couldn't see from that page, nor any other page I browsed on that site, anything that said it was on maintenance only. (Having only fixes between feature releases isn't 'maintenance only' in this context.)

[brucehoult]

cvs and svn are I think completely out of the question these days. I looked forward to both when they were new and they offered huge advantages over their predecessors and I campaigned to have employers switch to them.

These days I think you would be insane to choose either of cvs or svn over mercurial or git.

I haven't used mercurial all that much. It was necessary when I was working for Mozilla back around 2010. It didn't annoy me. It didn't excite me. It seems to do the job approximately as well as git. If you're already using mercurial there might not be any compelling reasons to change.

For a new project today (or in the last ten years) I'd go with git every time. It's battle-hardened, reliable, free, and has a huge community and tools ecosystem around it.

It does pay to learn a little about git's data structure and exactly how blobs, trees, commits, and branches actually work. It's a bit like how when you're programming in C, it's an advantage to have a rough understanding of what the machine code generated from your C will look like.

Also, I avoid using a lot of options with git commands. I like to explicitly add --no-ff or --ff-only to git merge to ensure the behavior I want, and often use "git commit -m" and of course "git submodule update --recursive --init" but I'd very very rarely use any other options. I'd rather use a short series of simple no-option commands that I know I understand. Definitely be *extremely* cautious about anything with "-f". Preferably just don't do it.

And always always check what you are actually changing with "git status" and "git diff" before you commit, and definitely before you push!

If you need to merge your own branch that you've been working on for a while with a heavily changed master branch where there may be conflicts then download and learn git-imerge rather than using the built-in tools.

[PlainName]

CVS is, and always was, pants. But I prefer svn over git any day. The major reason is because you have to work really really hard to screw it up, whereas with git you have to work hard NOT to screw it up (as you note!).

As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.

Also, I very often work on multiple branches at the same time. In git you work on one then switch to another, etc, or you're pushing and pulling and all sorts. In svn there's nothing like that. Commit here, work on that there, delete the entire copy... Each of those copies is just the working stuff, not the entire history of the universe replicated for each working copy. OK, you can make git more svn-alike in those respects, but it's hard work and not git-natural.

Git has benefits when multiple people are working on the same thing and effectively offline. The one thing I find git does better is let you hide intermediate local commits, but more often than not I manage to screw that up too

[brucehoult]

CVS is, and always was, pants. But I prefer svn over git any day. The major reason is because you have to work really really hard to screw it up, whereas with git you have to work hard NOT to screw it up (as you note!).

No, that's not what I said.

It's very very hard to screw anything up with git if you stick to simple commands and especially don't copy and paste overly-complicated gun-foot-bang "solutions" you find in random stack overflow answers. And don't "force" anything -- if it doesn't want to let you do it then there's a reason.

As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.

No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.

Also, I very often work on multiple branches at the same time. In git you work on one then switch to another, etc, or you're pushing and pulling and all sorts. In svn there's nothing like that. Commit here, work on that there, delete the entire copy... Each of those copies is just the working stuff, not the entire history of the universe replicated for each working copy. OK, you can make git more svn-alike in those respects, but it's hard work and not git-natural.

In git it's very easy to make multiple working directories that share the same local database. Simply do a git clone with a file reference instead of an ssh or https URL. The compressed database is just linked to, not copied.

svn keeps an entire duplicate copy of your working directory, completely uncompressed. git's "entire history of the universe" is often smaller than svn's backup snapshot, even for huge and long-lived projects such as llvm.

[magic]

Unless you --force something or remove the .git directory or delete files that have never been committed, your data most likely still exist.

[sleemanj]

Git won the war.  It's not the most deserving winner, but it won. 

Darcs is beautiful in theory but in practice unusable for anything serious.  Mercurial is a could-have-been-great contender but didn't get the critical mass.  SVN had it's time in the sun, but ultimately doesn't really fit well with how development happens these days, especially in the open-source world.

If you are making an open-source software and you want other people to be able to contribute to it, it really has to be git, and more so, on github.

[nardev]

As i lately do little bit of PCB design, i wish to see better integration with git and preview tools for previous version.

That would be really great. I really have problems when i have to go back in design, when i have to keep the prototype versions and continue making changes, even before PCB arrives.

It happened few times that i lost the design and the prototype PCB arrived so i had to think deep to reconstruct what i changed.

[PlainName]

    As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.

No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.

Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.

I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?

[PlainName]

Git won the war.  It's not the most deserving winner, but it won.

Yes, no question. One doesn't have to follow the herd, though - horses for courses

It becomes a bit of an issue when ones tools become obsolete because they are no longer popular.

[Veteran68]

I'm a git convert.

SVN is on maintenance, only bugfixes and minor performance tweaks.
Mercurial is dying.
CVS, is that still around?.

We've made it into a git monopoly...

Not sure where you heard that about SVN, it's not "on maintenance." It's still very actively developed and highly popular, especially in corporate shops. Although git is finally starting to take over.

As a software engineer going back to the mid-80's, I've used a lot of SCM/VCS tools. SVN was my favorite for a long time, but over the last couple of years I've slowly converted to git. My team still maintains our SVN server at work, but we are pushing people to git and most prefer it now, once they get over the learning curve. SVN tends to still be more intuitive to old-timers. Newcomers who have never used anything can usually pickup git quicker, since you don't have to unlearn traditional centrally managed SCM.

And CVS isn't dead either, unfortunately. I finally shut down our corporate CVS server last year, thankfully. SVN really should have put it to rest, but there are still holdouts.

[Nominal Animal]

For examples supplied here and in other forums, I use a directory structure with one example per directory, in a parent directory per forum.
Each directory has a short README text file explaining the example (and if I remember, an URL to the relevant post).

These do not need version control per se, but since I already have hundreds of them, finding relevant ones becomes the task to speed up.

I can throw a find or grep command in a few seconds to prune the set down based on a few key words I might remember, but to verify I have the correct example without reading the README or the source code itself, I add an Usage info block to each executable, telling me what it does as succintly as I can manage.  This way, I just run the executables in the candidate directories without parameters (or with -h or --help), to see if I've found the relevant example.  I've found it even helps when writing the code: it outlines the needed functionality before I write it.

For development of actual projects, for version control, I too use git.

[andersm]

As i lately do little bit of PCB design, i wish to see better integration with git and preview tools for previous version.

Overall, tool vendors still need to make more effort in making their files diffable and mergeable. Eg. Altera's Qsys uses XML project files, but has many bad design decisions that make it practically impossible to compare or merge changes. For example, connections between components were based on index numbers in a list, meaning that if components were removed or inserted anywhere else than at the end, they would all break. It also had endless list of Boolean config options, represented as long arrays of "Yes,Yes,No,Yes,No". So you could see that something had changed, but no idea of what.

[magic]

Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.

I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?

You certainly need at least one repo which never gets deleted

I think this problem is limited to SVN newcomers. Genuinely new users are told to create branches within repo instead of multiple repos. It is a workable approach IME; only when I really need to work on two things at a time and get tired of switching back and forth do I bother with multiple "workspaces" (still sharing the original .git directory).


As for Mercurial, I think it lost a lot by catering to noobs rather than to those who spoonfeed noobs

[tszaboo]

    As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.

No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.

Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.

I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?

One of the main reason at the company we switched to svn from git. besides all the EEs used svn before, and most git features were: "Why would I ever do that?" It fits better, because you have an actual version number, that you can print on schematic, or write into documentation. It also handles binary files better. Our sysadmin was mortified, when we told him we commit tens of MB large binary files to git.
For coding, git is probably fine, and could make more sense.

[PlainName]

because you have an actual version number

oh, don't get me started on version numbers!

No, go on then. How do you implement automatic version numbering such that a later commit is clearly a larger number? The aim of the game is to take this version and that version and be able to say, without perusing logs or charts or anything else, that version B is derived from version A rather than vice versa. (A timestamp would do it were it not far too long.)

[brucehoult]

It also handles binary files better. Our sysadmin was mortified, when we told him we commit tens of MB large binary files to git.

That's just wrong. git treats *all* files as binary. It handles large binary files such as disk images or databases, or image formats such as BMP or uncompressed TIFF, or even program binaries just fine, storing only the minimal differences between different versions.

What git doesn't handle is file formats where any tiny change results in almost every bit in the file being different, such as encrypted or already-compressed files.

[bd139]

I use Fossil for personal projects: https://fossil-scm.org/home/doc/trunk/www/index.wiki

It's written by Richard D Hipp of SQLite fame and is absolutely bomb proof.

Git is just horrid but at work it's the standard tool so I have to suck it up.

[Jeroen3]

because you have an actual version number

oh, don't get me started on version numbers!

No, go on then. How do you implement automatic version numbering such that a later commit is clearly a larger number? The aim of the game is to take this version and that version and be able to say, without perusing logs or charts or anything else, that version B is derived from version A rather than vice versa. (A timestamp would do it were it not far too long.)

Version control systems don't actually provide version numbers for humans. They just provide an identification of a particular state.
For version numbers you have to do something else. Such as https://semver.org/

[Cerebus]

Voted 'other' because: my favourite VCS of those listed would be mercurial but a need to collaborate with lesser morals means that git is the most used for me.

Edited to add: I too have been contemplating switching to fossil for personal work.

[PlainName]

Version control systems don't actually provide ...

My choice of words wasn't great

I am not asking about how to identify a version in relation to features, etc. That's a separate thing and, typically, manually sorted out. What I am asking is if I'm presented with two version numbers which both have the same semantic numbering IDs, how I can tell which is the newer one. In subversion the last field of the version number typically shows the commit reference, so that's easy. Also gives a small clue as to how far apart they are in changes. And also whether version X is actually version X or version X modified.

That isn't something svn implements, as I'm sure you know but I should state just to be clear. It is an external util that extracts the build reference and does whatever needs doing. It is a stunningly useful thing to have and I've not found a way of achieving the same using git. Hence my question.

[andersm]

I am not asking about how to identify a version in relation to features, etc. That's a separate thing and, typically, manually sorted out. What I am asking is if I'm presented with two version numbers which both have the same semantic numbering IDs, how I can tell which is the newer one. In subversion the last field of the version number typically shows the commit reference, so that's easy. Also gives a small clue as to how far apart they are in changes. And also whether version X is actually version X or version X modified.

You can use something like "git rev-list --count" to get the number of commits on the current branch, but that is something that is IMO better done by having eg. the build system inject the build number.