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

[magic]

This is just ... completely mistaken.

You're psyching yourself out.

Well, if you have only one copy of the repo and nuke .git with some bad invocation of rm then you are legitimately screwed indeed
Subversion kinda protects you by not being able to work that way at all.

I would still use git.

[SiliconWizard]

Uh... why turn this thread into a VCS flame war? It looks like git proponents tend to be fanboys sometimes. Calm down guys. Git is fine but has its shortcomings, and is relatively complex to grasp for users not familiar with VCS. Yes it can be used in a simple way with no risk if you restrict it to a small subset of commands, but then it's a bit like the whole C++ debate (like "C++ is fantastic is you don't use this and that feature, use a subset").

So suggesting something else is alright. The OP will then make its choice freely. Having options is a good thing.

[Kjelt]

Last generation only know Git, that is also what they are being taught at school, and it is a very good vcs so I can understand why they advise it.

[rsjsouza]

CVS was used for many years in my company without any of the issues mentioned here and it was replaced by the new kid on the block (Git) simply due to its discontinuation of support (last stable was in '08 or '09 IIRC). Did we have luck? Perhaps, but it was used by hundreds of developers across different sites, so I think it would be "lottery-winning" level of luck.

In any case, either SVN or GIT should work.

SVN is a bit loose when defining Tags and Branches and Git can be a bit dense, but for a single user in a contained environment both should work quite nicely.

[KE5FX]

If your application resembles the Linux kernel, where your role is to integrate pull requests from hundreds of contributors all over the world, then Git may be the best VCS for you.  That's literally what it was designed for.

Otherwise, Git probably isn't the best VCS for you, but you'll probably end up being browbeaten into using it anyway, just because "It's what all the cool kids are doing."

For individual use, Perforce works especially well.  It's free for single-user installations.

[peter-h]

"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."

That is exactly where I am, and have been for many years.

[james_s]

We use Git at work, I don't find it to be particularly difficult to use. There are about 5 commands that I use all the time and once I learned those commands I haven't had any trouble with it. I have not tried administering a Git repository though so I don't know how complicated it is to set it up.

[PlainName]

You could try svn and git and see which suits you. You never know - you might be a git person at heart

Being Windows based a GUI would be of big benefit. There are a few around but I would nearly always go for a Tortoise client if it's available, simply because they are robust, well proven and intergrate into the OS. You can have them all installed together since they don't interfere with each other (or anything else).

TortoiseSVN
TortoiseGIT

One of the hurdles to get going is having to create a project, create the repo, check in, do mode, check in, etc. But fortunately a zillion developers have given you a shortcut via github. Just go to a likely github project and checkout the source. Despite the name, github also provides svn access so you can get the same thing in the different clients for comparison.

Well, almost. Naturally, git and github are ideal for what they do there, whereas svn isn't. The upshot is that when you check out with git you download the repo as well, so repo access is very fast (unless you need to refer back to the github repo (aka the origin). With svn the repo stays at github, so any repo access (viewing the log or revision graph, for instance) involves a slow webdav transaction. Nevertheless, if you bear that in mind if gives you a good flavour.

Oh, also, if you pull the git version using the URL github supplies, you get a version of the code (plus the repo). If you do that with svn you get the entire repo contents (that is, all the branches and tags as well as the trunk), which probably isn't what you wanted. So with svn, do a repo browse to select what you want to pull down.

Edit: if you do get samples off github, bear in mind that checking any mods in will want to push them to github, which might be embarrassing. With git the changes will stay local unless you push to the origin so you should be safe, but I'd still not want to make a change and practise checking it in to someone elses live project... probably best to treat them as read only.

[brucehoult]

Git is fine but has its shortcomings, and is relatively complex to grasp for users not familiar with VCS.

I think the problem is more with the people who *are* familiar with another VCS, rather than the beginners.

[brucehoult]

Last generation only know Git, that is also what they are being taught at school, and it is a very good vcs so I can understand why they advise it.

Whereas I have used (at least): SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, Projector, Mercurial, Perforce ... and git.

Mercurial is a bit of a toss-up on features, but git wins by far on ecosystem. The rest -- I'm never going back. You can't make me.

I'm especially not ever going back to anything that requires a team member to get an exclusive lock on a file before they can make even experimental or temporary changes to it.

Perforce has one useful feature of being able to map portions of a vast corporate repository into your workspace, but is otherwise an abomination.

[Kjelt]

Whereas I have used (at least): SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, Projector, Mercurial, Perforce ... and git.

That brings back memories, I also was the "victim" of some of those.
The worst IME was IBMs Clear Case, oh man that was cold war thinking stuff where you need tons of permissions, grants and so on before you coukd change one line 

[Siwastaja]

Git is like make, it's not perfect for every task but is easy enough, and widely used enough, so people just learn some subset and get on with their lives, to do the actual work.

Comparison to C++ is invalid because working with the programming language is the actual work, while version control is just a tiny auxiliary task (which is there to save time) and if it is taking any significant time then something is definitely wrong. Fanboys of course can dedicate their lives on managing the VCS. But today git's so widely used that true fanboys are 0.01%.

Hence, for a software project, you absolutely must understand how to use the programming language of choice, and the subset can't be small. But a more limited experience in the VCS can be acceptable to just get that part of job done.

[westfw]

The worst IME was IBMs Clear Case

STOP!  You're triggering me!
Sigh.

[dl6lr]

First of all you should never mix up backup strategy vs. version control. A version control system is no backup, if you remove the repository by accident, be it on the same computer or on a different one, you are fucked up if you have no backup. If you have a backup of your project, you do not have a version control. So be prepared to have a version control system *AND* a scheduled backup of your repository/work.

Having used several VCS, we migrated from CVS to SVN in the past. Now I am migrating our software development to git. For my personal stuff I moved to git years ago, in the company I struggled with several organisational aspects (one being the NIH-syndrom).

Don't be fooled by statements that SVN is protecting you against removing your repository by accident: if you are using a repository on your hard disk, you have the exact same situation as with git. If you have a remote repository, you cannot work stand alone with SVN. With git you can have both.

Bernd

[PlainName]

if you are using a repository on your hard disk, you have the exact same situation as with git.

This is wrong.

To lose the subversion repo you need to delete the repo. Nothing you can do where you're actually using the data can zap the repo.

To lose the git repo you delete the working directory. Hopefully you will have pulled it from some upstream place, so you can re-pull it, but if you haven't pushed changes upstream as well as checked them in locally they are toast.

[Siwastaja]

You mean that by default git stores the objects in .git subdirectory of the working directory. If this is what you mean, then yeah, a recursive removal of the working directory and all subdirectories including those starting with ., yes, it's gone.

Of course it's highly recommended to have some upstream where to push, preferably accessable from the interwebz. Like github or similar, very easy to set up. This enables you to continue working elsewhere as well.

[PlainName]

If you have a remote repository, you cannot work stand alone

This is also not quite true. You can use svnsync to mirror the remote locally (or not-so-remotely as the case may be).

To be more precise, I think you mean you can work unintentionally offline with git (but, of course, then hit the single point of failure issue and delete everything).

[PlainName]

If this is what you mean, then yeah, a recursive removal of the working directory and all subdirectories including those starting with ., yes, it's gone.

That's what I do regularly. I'll be working on something in R:\project\working and have a  bright idea or want to test something so create R:\project\temp. Do stuff, don't need it any more, erase ~\temp. With subversion any changes I checked in I can then pull into ~\working. With git they are gone unless I pushed them to ~\working after checking them in. And before deleting them, obvs.

Now, admittedly, I haven't done that since the second time I accidentally did it, but I am forever fearful of exactly what I am deleting when I vape no longer required working folders. OTOH, I don't want a load of empty, except for .git, folders littering my storage. With svn I just don't give it a second thought because there is nothing critical anywhere an editor or delete command is going to be used. The worst I can do is check in some absolute rubbish that will be preserved for posterity.

Now, you may think that a workman likes sharp tools. Indeed, that is a generally safe view, but OTOH I don't use a slot drill to make a hole.

I am not suggesting git is rubbish - it is excellent at what it was designed for. But a single developer not collaborating with world+dog, wanting a simple tool, was not Linus' target.

[emece67]

.

[brucehoult]

To lose the git repo you delete the working directory. Hopefully you will have pulled it from some upstream place, so you can re-pull it, but if you haven't pushed changes upstream as well as checked them in locally they are toast.

If this is seriously a problem for you, then do..

Once:

Code: [Select]

sudo mkdir /opt/git
sudo chown $USER /opt/git

(or anywhere else you want)

And then for each new project:

Code: [Select]

git init --separate-git-dir=/opt/git/foo foo
cd foo

Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.

[magic]

https://git-scm.com/docs/git-worktree

I also used to symlink .git to multiple workdirs long before this option became available, but it had the downside that the current branch must be changed each time you move to a different checkout and you have to be careful not to overwrite files by accident.

edit
For a complete subversion experience, you could (presumably?) keep --bare repositories somewhere in one place and as many checkouts as you want elsewhere. Then you know that each workdir can be nuked at any time and only uncommitted changes are lost.

[olkipukki]

How do people solve this?

Many words been said about Git and easy to follow 'do just as we do' 

Gladly, there is another alternative - all-in standalone minimalistic DVCS with build-in extras that works well on Windows, macOS, Linux (Ubuntu,SUSE) and FreeBSD

https://www.fossil-scm.org/home/doc/trunk/www/index.wiki

2.0 Differences Between Fossil And Git

https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

[PlainName]

Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.

That is what I do, but push to it every time. Obviously. And that allows it to get backed up properly too. But since that's exactly how and why I use svn, I'm wondering why this is better when it takes more steps, leaves more debris and isn't the way it's meant to be used.

[newbrain]

The worst IME was IBMs Clear Case, oh man that was cold war thinking stuff where you need tons of permissions, grants and so on before you coukd change one line 

Damn, I though I had recovered from that experience and mostly removed that abomination from my memories, but I still shiver reading about it.

I still remember that in any project, even smallish ones, we needed more or less one FTE configuration manger as a human sacrifice to placate that ghastly beast.
Also their firstborn or spouse, if one more branch was needed.

[PKTKS]

More 2 cents...

Apart the chosen method...  not surprisingly PERL can put a common abstract layer easily on every one of them...

• https://metacpan.org/pod/Rcs
• https://metacpan.org/pod/Cvs
• https://metacpan.org/pod/SVN::S4
• https://metacpan.org/pod/Git

PERL has been my preferred  method for abstract interfacing any of them...

you know.. things change over time and it is very good keep sanity

Paul