A version control system for embedded work, which doesn't need a PhD

[peter-h]

Currently I do an automatic  daily backup at 3am, plus occassional (3-4 times a day) backups which are preserved separately, and of the entire Cube IDE project directory.

Apart from the Cube IDE application config (under c:\st\.... \Configuration) which I also backup sometimes, and the Cube IDE installation itself (under Program Files) that is the entire project.

Various people tell me this is a crap approach and I should use proper version control. I know basically what it is (many years ago I used PVCS) but need something simple which I can understand.

So I did a google. And I see a ton of garbage, like this https://www.newelectronics.co.uk/electronics-technology/version-control-for-embedded-software-engineers/155521/ where it claims

The IoT is at risk of taking us back 30 years to the time when network stacks were being built without inherent security measures in place, therefore risking, for instance, massive DDOS attacks.

which is BS. A DDOS attack is not going to happen just because you have poor security. It will happen because somebody doesn't like you, and wants to saturate your internet connection And if you have bad security you don't need a DOS attack to break in. So when I read something like that, the rest of the article is likely to be BS also.

There there is BS like this: https://www.embeddedcomputing.com/application/industrial/7-steps-to-choosing-a-version-control-system

Git is said to be popular but looks incredibly complex. I've been programming since about 1980 but my eyes glaze over when I read this

My recollection of VCS is that you are basically replacing one backup location, which can get trashed if the machine blows up (so you keep copies in different places), with another backup location (which can get trashed, and is actually more likely to get trashed because you are storing the original plus a load of diffs, so to get back to version x you need to unwind y diffs, and if there is any data corruption, you have a disaster because the whole structure is binary and you just end up with a mess. This actually happened with PVCS; people got trashed backups. It's the same issue with differential backups (regardless of the media used) which (in general) nobody uses for anything critical IF they can back up the whole project every time.

The VCS archive needs to be stored somewhere and that will be the ultimate weak point. So you now need to back that up as well, and keep different versions

How do people solve this?

[PKTKS]

There are a plethora of methods...

Mostly they are really UNIX methods..
just because .. you know.. MS is a BS GUI shit.

RCS is the most competent method for pontual control

** IT DOES RUN ABSOLUTE FINE UNDER CYGWIN **
as most POSIX compliant tools - but you know.. MS will never support CYGWIN

http://www.cs.purdue.edu/homes/trinkle/RCS/

Alternative CVS  predates GIT and IMHO is simpler.
it does the puddin

 http://www.cvshome.org/

Anything site wide with timely pontual relies on RSYNC
the defacto daily hourly fast backup

Paul

[PKTKS]

Yes... SVN  stands aupar with CVS both predates GIT
and are less powerful but simpler alternatives for branch revisions

Paul

[peter-h]

I use Cygwin and Rsync; have done for many years.

I did read the description of Git starting here https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F but anything which needs a "book" is out of the question

[artag]

You don't have to use it all, though. Much of git's strength is it's ability to do useful merges when multiple people are working on the same code. It's quite likely this is never the case for you, and you can use it as backup and version-keeper by learning only about 3 commands (add, commit, pull).

If you need more, learn that part only when you need it.

[SiliconWizard]

As I already talked about earlier, I do use Mercurial for this, when using git is not a requirement.
Mercurial definitely ticks all those boxes. It's much simpler to use than git, yet it's also a distributed system, so you can use it locally with no server. Some will say it's less powerful than git, but you're much less likely to shoot yourself in the foot with it. Just my 2 cents.

[peter-h]

One thing I have realised, after a few near-disasters with Cube IDE, is that there needs to be a feature where you can state that a whole directory must always be backed up whole, for mutual consistency.

For example when working on Cube, you need to backup the project, and you need to backup the Cube config which is e.g.
C:\ST\STM32CubeIDE_1.4.0\STM32CubeIDE\configuration

and there is ~10MB of files there



Mercurial looks like a command line tool. That's ok.

AFAICT all these write stuff into the header of every text file, detailing changes, using a text string which you enter just once for that backup. That is quite useful because while I insert a change log into source files, sometimes I forget.

Multiple workers makes things much more complicated but I am not doing that normally. If I work with someone, they will be doing a quite specific portion of a project.

[Kjelt]

I assume you run Windows or Linux?
In that case I can advise SVN tortoise.
It is a shell and fully integrated with windows such that for instance when you look at a folder in Windows explorer a red flag or green V symbol on the folder icon and all the maintained file icons will immediately tell you what files changed and which not.
It is very easy to learn (2 hours tops) but indeed you need to store an archive called repository somewhere preferrably not on the same computer but for instance a NAS.
Then you can checkout the repository on any computer you want or twice on the same computer if you want.
Comparing is easy although I prefer a $25 once a lifetime special tool from scootersoft called Bcompare for this, and you can with checkin automatically update/change some header info (you need to add some specialcharacters) so you can see the date time and version of a file without theneed tose svn.
Many options but try it out or watch a demo. Once used to version control you don’t want to go without.

[janoc]

There are a plethora of methods...


Alternative CVS  predates GIT and IMHO is simpler.
it does the puddin

Uh, please no. I know you have issues with a lot of modern things but there is really no reason in this day and age to use CVS. You are really giving out strongly opinionated advices that are both terrible and in this case could directly lead to a data loss.

Just one example CVS problem out of many - it will happily commit half of the changes in your working directory and then barf because it has discovered a merge conflict. And now you have half of your changes committed on the server (where someone else can fetch it and start working on it already!) and half not. Yay!

CVS also loves to corrupt the individual RCS files on the server - had to fix those manually using a text editor more than once back in the day. Really really not a system that you can and should use for actually safeguarding your work today.

It was a step forward compared to SCCS and RCS back in the early 90s but it should be left in the grave today. The last stable release was in 2008, that should tell you something about how maintained (e.g. for security vulnerabilities) it is.

If you really hate git for whatever reason, use at least Subversion (SVN). It fixes both the lack of atomic commits (the entire commit either passes or fails, it is never partial as can happen with CVS which operates file-by-file), the repository is much more stable than anything CVS ever had and merging is more sane. And it is actually still maintained.

[sokoloff]

You don't have to use it all, though. Much of git's strength is it's ability to do useful merges when multiple people are working on the same code. It's quite likely this is never the case for you, and you can use it as backup and version-keeper by learning only about 3 commands (add, commit, pull).

If you need more, learn that part only when you need it.

Came here to say basically this (well, with the addition of "push").
For a simple use case with only one developer (you), git provides a relatively smooth on-ramp and you can ignore 97% of the features.

Combine this with a (free) github.com account, you can do offsite backups of the git repository to your github account and not worry about losing all your code in the event of loss/breakage of your local workstation.

[PKTKS]

There are a plethora of methods...


Alternative CVS  predates GIT and IMHO is simpler.
it does the puddin

Uh, please no. I know you have issues with a lot of modern things but there is really no reason in this day and age to use CVS. You are really giving out strongly opinionated advices that are both terrible and in this case could directly lead to a data loss.
..

Never had a single issue with CVS SVN or RCS. I have used them extensively over 90s 00s.. but GIT had tookover all relevant issues

Nevertheless they are simpler

RCS is really the tool which GIT can not replace.

But i manage my systems myself so LIBC and compilers are carefully controlled reason why i should had better results

Paul

[westfw]

RCS is pretty straightforward, and still useful (IMO) for single-person, local, use.  I rather like having to explicitly "check out" files before you can modify them (which seems to have gone out of style.)

But git is a lot more popular, has more tutorials, interfaces to places like github, is supported by IDEs and GUIs, and so on.

Almost every VCS is "very complex" if you want to use all of its features, but the subset that most people need to do useful work is much smaller and more manageable.

Note that VCS and "backups" are not really the same thing at all...

[janoc]

Never had a single issue with CVS SVN or RCS. I have used them extensively over 90s 00s.. but GIT had tookover all relevant issues

Consider yourself lucky. There are plenty of well documented warts and problems with CVS/RCS that would easily cause data loss or hard to recover from situations. Plus using it on large repositories with a lot of binary files (e.g. imported vendor binary blobs) is a huge, slow pain.

Nevertheless they are simpler

RCS is really the tool which GIT can not replace.

Of course. RCS is a design from mid-80s so no wonder it is simpler and GIT is not designed to replace a versioning of a single file by a single user. Which is all that RCS does and which you really rarely need when working on a code or PCB project, as opposed to e.g. managing a bunch of independent configuration files (but even for that there are better solutions these days).

But i manage my systems myself so LIBC and compilers are carefully controlled reason why i should had better results

No, you just got lucky and likely use the system in only an extremely basic manner where you didn't hit any of those issues.

Those are problems inherent in the design of CVS/RCS and nothing to do with libc or compilers. If you get a commit broken up because of a missed merge conflict (or a locked/corrupted file or some server-side problem), your can hack around on libc and your compiler as much as you want and it won't help you any.

It is not some kind of bug, it is the direct consequence of CVS having no idea of a "commit" (or "change set") but only acting as a frontend to RCS over the individual files where it commits each file separately with the same message. It is pretty big pain and a difficult situation to recover from, especially on a large project. There is a reason why you won't find anyone except some old legacy GNU stuff using CVS today.

[voltsandjolts]

Almost every VCS is "very complex" if you want to use all of its features, but the subset that most people need to do useful work is much smaller and more manageable.

^^ This.

I would recommend to go with GIT purely because its mainstream and there is lots of help available. Start by watching you-tube videos about GIT, great resource there.

If you want a GUI and your running Windows or Mac I would recommend trying Sourcetree https://www.sourcetreeapp.com/

[emece67]

.

[Kjelt]

So is the TortoiseGIT also a shell around GIT just as TortoiseSVN is for SVN?
Then I also might switch to it, is there to your knowledge a way to migrate from SVN to GIT only to preserve the many years of logging , which I often use to see when a certain change was made and the logging for the reason ?

[Siwastaja]

Just use git. It's the most popular for a reason. You don't need to use all fancy features. It's not the easiest thing available but easy enough. If you can write embedded code that works, you can learn git in a few hours during actual work.

I didn't initially like it and I still don't think it's the best thing since sliced bread but it's widely known and does the trick just fine. It takes a few hours to get started but learning curve is still negligible.

Just say no to CVS or SVN. Especially in small projects the requirement of having a server is an issue.

[sokoloff]

There is:
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git

I had poor results from TortoiseSVN, mostly relating to how slow it was in our large repository (probably made worse by anti-virus), but both of those are just wrappers around the underlying revision control operations, so if it works for you, it will work with git as well. (Git was designed from early on to have a backend set of functions [plumbing] and multiple front ends [porcelain].)

[emece67]

.

[Kjelt]

Thanks looks familiar.

Yes, but keep in mind that the Git approach is not the same as the SubVersioN approach, so the menus are different. See below (left TortoiseSVN, right TortoiseGit).

I figured as much seems logical but thanks for the warning.

[DiTBho]

Git + backups
don't underestimate backups!

[brucehoult]

As I already talked about earlier, I do use Mercurial for this, when using git is not a requirement.
Mercurial definitely ticks all those boxes. It's much simpler to use than git, yet it's also a distributed system, so you can use it locally with no server. Some will say it's less powerful than git, but you're much less likely to shoot yourself in the foot with it. Just my 2 cents.

git is perfectly simple. You only need about five commands. You don't need lots of fancy options on the commands. You can always use a sequence of two or three simple commands instead.

You can't shoot yourself in the foot with git if you refrain from using "force" options on commands to make git do things that a VCS should not let you do. The job of VCS is to preserve the history of the project. You committed the wrong thing? That's unfortunate, but now it's part of the history. Commit the right thing and be more careful next time.

[PlainName]

At a previous company we used VCS and then PVCS. It was OK but a real drag to revert to a snapshot of the system - somehow you'd need to know it's this version of that file, that version of this file, etc. We solved that by applying a label across all files when we did a release (or just because), but per file versioning wasn't the way to go.

After some travels, paying for a quite reasonable system that's no longer appropriate or available, I settled on Subversion. Unlike xVCS it versions a project in its entirety, which is far more sensible. Subversion also comes, with the aforementioned in the thread, TortoiseSVN Windows client, which makes the whole thing very simple and easy to use. No remember arcane command lines, batch files, whatever - it's all embedded in your file manager (and hopefully you use a decent one, like DOpus, rather than Explorer, but it doesn't matter - TortoiseSVN integrates with them all).

World+dog has gone git mad, and any random hip developer will insist git is the only proper way to go now. Git is good for what it was designed for, which isn't what many of us are doing. There is a TortoiseGIT client for Windows (this stuff is what keeps Windows relevant for development IMO) but it's still git and easy to screw up in many weird ways.

Subversion scores for me because it has a master repo (you can have mirrors and change where the master is, but it's a star topology). Where you do stuff is just a checked-out copy that has no bearing until you check it back in. Practically, that means you can do silly stuff which affects the core of the versioning (like merging with completely inappropriate options) and end up with a completely trashed and worthless copy. No problem: just delete it, check out another and try again. I usually have several copies of the same thing checked out - one might be for trying stuff on, and another the real working copy. None of them are important and I can delete them as and when I like.

It really is difficult to screw up subversion. Even if you willfully break things and then check it all in so the repo is polluted, you can just go back to the previous revision and bypass the mess you snuck in there. I think you need to actually delete the repo to score a hit.

With git, you can't do that so easily. The working copy is THE authoritative repo and if you vape the folder you will lose the lot. Sure, you can make copies and all that but keeping track of what's where can be a hassle. I usually have a master repo and then push stuff to that at every check-in so it acts like the master repo. But essentially it is forcing a square git into a round process.

Git does have advantages when it comes to branches and merging, although it's not as foolproof as the walk-throughs and how-tos make it look. For a single developer used to backups as version control, it is way over the top and more likely to put you off than solve anything.

For subversion, I keep the repos on a  NAS. The NAS is backed up every day en bloc and things like the repos folder(s) are separately backed up to alternative media. There is no problem having the repos on your main PC and having those backed up as anything else would be. Having them off-PC doesn't really protect against ransomware unless you keep them offline when not actively accessing them, but offline backups are a step in the right direction (although not infallible).

[brucehoult]

It really is difficult to screw up subversion. Even if you willfully break things and then check it all in so the repo is polluted, you can just go back to the previous revision and bypass the mess you snuck in there. I think you need to actually delete the repo to score a hit.

With git, you can't do that so easily. The working copy is THE authoritative repo and if you vape the folder you will lose the lot. Sure, you can make copies and all that but keeping track of what's where can be a hassle. I usually have a master repo and then push stuff to that at every check-in so it acts like the master repo. But essentially it is forcing a square git into a round process.

This is just ... completely mistaken.

You're psyching yourself out.

[smithnerd]

I found this site useful for understanding why git is designed the way it is:

http://think-like-a-git.net/