Version Control

[SiliconWizard]

I slightly hoped this thread had died.

Well, the voting part is definitely , but hearing from others their preferred workflow is definitely interesting.

It's still growing a bit. Dunno if it'll reach the 100 I was aiming for (to get figures remotely usable), but getting closer.

Dunno why the thread should die? Yes knowing what kind of tools and workflows other people use (and in which context) is always interesting, and from the perspective of EE, even more so.

BTW, version control is not just for software either. So people can keep that in mind and further tell us how they manage version control for hardware development for instance.

[PlainName]

version control for hardware development for instance

Same as for software (quite adventurously) - commit to save the current state, branch to try something. Merging is the same too: I never use the SCS merge facility (or rarely) but prefer to manually merge, either by actually merging or just copying one version over another, depending on whether there are other changes around.

Also use version control for other stuff. Sometimes I do a bit of copy editing and it comes in useful then. My partner tried to emulate that but couldn't get to grips with is so resorts to the old numbered zip backup routine.

I know of someone that uses subversion to sync stuff between machines, much like Nextcloud might do.

[SiliconWizard]

version control for hardware development for instance

Same as for software (quite adventurously) - commit to save the current state, branch to try something. Merging is the same too: I never use the SCS merge facility (or rarely) but prefer to manually merge, either by actually merging or just copying one version over another, depending on whether there are other changes around.

I do that also, but many people don't, with the rationale that most CAD files are not text-based and thus are not well adapted to standard VCS (for instance, you can usually not "diff" them.) Some CAD software have (often very expensive) options for specific version control.

I know of someone that uses subversion to sync stuff between machines, much like Nextcloud might do.

Using some kind of VCS to sync between machines isn't a bad idea. Not only does it handle the syncing part, but it does so without ever permanently overwriting stuff - you always keep your whole history.
Not the most efficient storage wise, but storage is not expensive these days.

[PlainName]

I mean to say 'unadventurously' Speling cheker got to it

[Nominal Animal]

BTW, version control is not just for software either.

I've actually dabbled in developing a Linux server configuration file change tracker, which automatically records changes to superuser-owned configuration files, tracking each changeset to the logged in user (by traversing the process tree at the moment the file was opened).  This would be useful in situations where you have several users who habitually do the equivalent of sudo su - when doing maintenance stuff, and who refuse to accept responsibility when they fuck up.

It is possible to implement this via the audit subsystem, interposing the standard C library, file leases, or via the fanotify interface.

Essentially, changesets would be copied to a separate directory immediately as they occur, with some metadata (save time, duration from open to close, process ID, the process chain up to the logged (console/SSH) user), so users/admins would not notice any delay, and are not limited by the tools they use; even find ... -exec sed ... ';' type of command chains are perfectly okay.  A separate daemon would diff the changes at its leisure, and push them to a database of some sort; either in patch format, flat files, or perhaps even a git tree.

So, it is a very limited form of automatic changeset recorder, not really version control; but close.

Unsurprisingly, sysadmins are not keen on having their work monitored at that detail, even if it meant fuckups could be traced to whoever caused them.  Or perhaps exactly because of that.

[SiliconWizard]

Unsurprisingly, sysadmins are not keen on having their work monitored at that detail, even if it meant fuckups could be traced to whoever caused them.  Or perhaps exactly because of that.

Well, if your system only allows to track changes, I can see why they would not like it. Now if it also allows to keep the history and revert to any earlier state (like a VCS would), I think they could see the benefits: sure it would monitor their fuck-ups, but would also allow them to revert back easily when they do fuck up, and much faster than having to restore a full backup.

[bd139]

We just use auditd that ships with CentOS for that. You can auditd logs are piped into Elasticsearch/Kibana in AWS and alerts configured. As for config changes, ALL config is stored in VCS + ansible. If someone farts I know.

Now we're moving to k8s so there's not really any OS to configure or worry about.

[BloodyCactus]

I currently do everything through git. I've gone cvs->vss->svn->bzr->git.

visual source safe ate more code than it ever protected ugh and I quite liked bzr..

I use git for a lot of things at home and at work. at work we have it like an installation center, clone a version of the jdk, clone tomcat. done, tomcat server now deployed.

I have my diptrace cad in git at home, but I never merge with git for my cad files.

If I am working on something, I will often just create a local git repo, do some work, maybe stash or branch and test some things then blow the local repo away. Not everything needs to be stored forever and sometimes you want to just test a tweak or change.

[mrflibble]

There we go. One vote closer to that 100 target. And yes, +1 for git.

Have used cvs in the past, svn after that, and git after that. Have used mercurial in the past as well, and would not mind it for new projects. I most certainly would not use cvs again in any new project. Subversion, mmmmh, maybe, provided the project will not have more that a few feature branches over the entire project lifetime. And also provided there is a good reason to pick subversion, lets say because product xyz has good subversion integration, and nothing else (version control wise).

[SiliconWizard]

Looks like we reached (and even exceeded) 100 votes. Just a couple comments.

With 62% for git, we are nowhere near the 80% to 95% figures we often see for pure software development. I'm not all that surprised, this was also the point of this thread: having a look at what EEs use for version control (when they use anything.) One of the reasons is probably that a number of them work at companies in which other systems are in use, which is more common in other fields than pure software dev.

Still regarding git, as others have noted here, a significant fraction of users are probably using this more as a remote "incremental" back-up tool (many using github due to its popularity) rather than as a true version control system.

For CVS, there is no contest here, except for a few organizations that still use it, it has been largely superseeded by SVN (for a similar centralized approach) for a long time now.

We can note that SVN is still used for a non-negligible fraction of people, something that seems consistent with what I've seen in industrial settings. The fact that it's a centralized system, with its pitfalls, is actually still seen as a benefit for some organizations, or even a non-negotiable feature.

The "other" choice probably includes in-house solutions as well as commercial ones, and it's not a negligible fraction either.

I'm not sure why Mercurial has so few users. It was actually released slightly before git initially, and clearly git was not meant to "compete" against it as (AFAIK) Linus Torvalds didn't even really know about it at the time he was designing git, and he never cared. The fact Mercurial was written in Python is likely a factor that would have made him ignore it completely anyway.

Whereas I don't like Python much for a number of reasons, I do like Mercurial. It's clean, it's simple, it's consistent, and it doesn't have myriads of options to shoot yourself in the foot like git does. I haven't really ever seen clear points/facts against it from people not using it. They are just not using it, but for no real reason other than popularity of other tools. I found the following article: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket (which was linked by some poster here) pretty idiotic. The introduction itself shows a complete lack of knowledge of Mercurial, yet the article is supposed to explain why abandon it. Quoting:

The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supported Mercurial repos.

Mercurial is absolutely NOT a centralized version control system. It's distributed just like git is. Face palming introduction. The only real rationale for abandoning it was just lack of users, nothing technical. Whereas it has little popularity compared to git, it's still used by a number of very large organizations, including Mozilla.

Back to git: I personally think this was designed (and is adapted to) much more for maintainers than for contributors, which absolutely makes sense knowing why and what for Linus designed it.

Finally, regarding the numbers themselves, we can see that version control doesn't seem to interest/is probably still not used by many EEs. This is not very surprising either. Generally speaking, a strict process for handling hardware modifications is still a relatively rare thing in many companies (except those in regulated fields such as avionics, medical devices, etc.) from what I've seen. Whereas it can absolutely be done with other tools than version control systems, I've found that it was pretty often not done at all, or at least with too little discipline.

[PlainName]

Finally, regarding the numbers themselves, we can see that version control doesn't seem to interest/is probably still not used by many EEs.

Alternatively, not everyone that viewed the thread could be bothered to vote, and not every user of the forum saw the thread. I don't think you can extrapolate that a mere 103 votes (which, actually, I think is a lot in context) means hardly anyone else uses a VCS.

[PlainName]

Christ, I HATE git.

Simple problem: got a cloned repo. Massive thing but not a problem because it's all under version control. Clone it to a local bare repo to record my changes, etc. Hmm... seems a bit small... oh, half the thing is sub-modules which don't get pushed. Not no way. Never mind, just export to a zip and stash that somewhere. Nope, no sub-modules in that either. WTF? Are they kidding? No matter what I try I just can't get a simple copy of the damn thing and remain under version control.

Fixed by checking it all into svn.

[Bassman59]

Christ, I HATE git.

Simple problem: got a cloned repo. Massive thing but not a problem because it's all under version control. Clone it to a local bare repo to record my changes, etc. Hmm... seems a bit small... oh, half the thing is sub-modules which don't get pushed. Not no way. Never mind, just export to a zip and stash that somewhere. Nope, no sub-modules in that either. WTF? Are they kidding? No matter what I try I just can't get a simple copy of the damn thing and remain under version control.

Fixed by checking it all into svn.

The only advantage git offers over svn is the distributed aspect, which allows users to make changes and keep track of them without needing access to the original repository. And then when the user is happy with the changes, they can be pushed back to the original repo.

You can do that with svn, too. Just make a private branch and commit to it. And then when you're done, merge back to the trunk.

Follow any project that uses git and there are always mailing-list questions along the lines of, "I borked my clone, help!"

[bd139]

I just send the https://ohshitgit.com and job done 

[SiliconWizard]

Do not hesitate to take a look at Mercurial if you have a problem with git. Seriously.

[PlainName]

I've considered it several times. The only reason I use git is because it's required to access third-party code, so it's not like I am trying to gain git features without the pain of it being git. Mercurial doesn't have good penetration, so where some product offers built-in source control it will be typically subversion and now git, but not Mercurial. Usually that wouldn't bother me because I rarely use the built-in stuff anyway, but it's an indicator of industry support and I've been bitten previously by jumping ship to something that gets binned shortly afterwards.

[0db]

I've considered it several times. The only reason I use git is because it's required to access third-party code, so it's not like I am trying to gain git features without the pain of it being git.

I have been using git for personal projects since 2009.  I haven't yet found any problem and I never felt frustrated with it.

[bd139]

It mostly goes to hell when you have to collaborate. Some quotes from our company Slack last week:

"i can't discard the changes, if i stash them they come back again"

"That will be a line ending issue. Git will be converting LFs to CRLFs automatically"

"we could normalise all file endings to solve the issue, but that will be a massive PR"

"any idea why these files seem to change on everey pull:"

"any ideas how to paste into a git bash terminal without insert key?" (yes new HP elitebooks they gave to our devs dont have an insert key)

"arrgghhhh this gitattributes issue just keeps reappearing"

"that's happening because we have some devs on macs and some on windows"

etc etc

If you want to fuck someone up on windows from a Linux box you can do this as well:

$ mkdir hAhA
$ mkdir HaHa
$ git commit -a -m "Hahaha fuck you windows devs"
$ git push

[brucehoult]

That's not going to work, because one of git's few actual design faults is you can't add an empty directory 

[bd139]

  Still drinking my first coffee of the day. 

Add a file to each dir

Also, works in SVN 

[PlainName]

I haven't yet found any problem and I never felt frustrated with it.

How would you fix my requirement that provoked this thread? I have a cloned repo that I am working from and want to record my changes locally - they won't be pushed back up to the origin. I need a robust authoritative 'master' repo that will be on a global backup and won't be messed with during normal work. Or even abnormal work. With svn that would just be The Repo from which I would checkout my working copies, so a bare git repo would seem to be the best choice.

I have no idea where the submodules originate or where their origin repos are. All I know is that the source files appear in the main source tree, and whatever the current state of play of them is, that's what I want to store. Apart from which, there are far too many to dick about manually chasing them down and dealing with them separately.

[Cerebus]

This is not helped by the fact there are different ways to do submodules, including some semi-manual hacks that a lot of people like to use. (I'm giving a former colleague a Paddington Hard Stare over the aether as I say that last bit.)

Read:
    man gitsubmodules
and
    man git-submodule

and then try:
    git submodule status

and, if you're lucky and they have done things "by the book":
    git submodule update
will get you to where you want to be.

[bd139]

I've spent the last two weeks thinking that perhaps I should write something better than git. And register whateverhub.com

[PlainName]

Thanks for the advice, but...

git submodule update

That would update the submodule to the current version at the origin, wouldn't it? I just want a copy of what I have right here on my disk, not change it for something I haven't tested yet

[Cerebus]

Thanks for the advice, but...

git submodule update

That would update the submodule to the current version at the origin, wouldn't it? I just want a copy of what I have right here on my disk, not change it for something I haven't tested yet

Must have misunderstood you, I thought that you had missing submodules and that would slurp the latest/currently tracked SHA from the remotes (assuming they had been correctly configured, and the original producer had done the proper configuration of remotes).

Herein lies the problem with git, it's fragile and the slightest missed step or misconfiguration when you're trying to actually use features can tear the whole house of cards down.