Poll

What's your favorite version control system?

git
87 (68%)
mercurial
5 (3.9%)
svn
19 (14.8%)
cvs
1 (0.8%)
other
16 (12.5%)

Total Members Voted: 128

Author Topic: Version Control  (Read 5175 times)

0 Members and 1 Guest are viewing this topic.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 1775
  • Country: fi
    • My home page and email address
Re: Version Control
« Reply #100 on: February 13, 2020, 02:27:32 am »
I slightly hoped this thread had died.
Well, the voting part is definitely :=\, but hearing from others their preferred workflow is definitely interesting.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5452
  • Country: fr
Re: Version Control
« Reply #101 on: February 13, 2020, 07:16:12 pm »
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.

 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #102 on: February 13, 2020, 07:27:07 pm »
Quote
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.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5452
  • Country: fr
Re: Version Control
« Reply #103 on: February 13, 2020, 07:46:48 pm »
Quote
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.
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #104 on: February 13, 2020, 08:21:31 pm »
I mean to say 'unadventurously' :) Speling cheker got to it :(
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 1775
  • Country: fi
    • My home page and email address
Re: Version Control
« Reply #105 on: February 14, 2020, 12:58:22 am »
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.
« Last Edit: February 14, 2020, 12:59:59 am by Nominal Animal »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5452
  • Country: fr
Re: Version Control
« Reply #106 on: February 15, 2020, 03:02:12 pm »
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.

 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15527
  • Country: gb
Re: Version Control
« Reply #107 on: February 15, 2020, 03:47:39 pm »
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.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 480
  • Country: us
    • Kråketær
Re: Version Control
« Reply #108 on: February 19, 2020, 01:59:54 pm »
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.
-- Aussie living in the USA --
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2024
  • Country: nl
Re: Version Control
« Reply #109 on: February 27, 2020, 07:13:05 pm »
There we go. One vote closer to that 100 target. And yes, +1 for git. :P

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

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5452
  • Country: fr
Re: Version Control
« Reply #110 on: March 27, 2020, 06:33:07 pm »
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:
Quote
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.

« Last Edit: March 27, 2020, 06:37:24 pm by SiliconWizard »
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #111 on: March 27, 2020, 07:02:05 pm »
Quote
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.
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #112 on: April 13, 2020, 06:21:45 pm »
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 following users thanked this post: Bassman59

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1521
  • Country: us
  • Yes, I do this for a living
Re: Version Control
« Reply #113 on: April 13, 2020, 08:11:54 pm »
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!"
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15527
  • Country: gb
Re: Version Control
« Reply #114 on: April 13, 2020, 08:12:45 pm »
I just send the https://ohshitgit.com and job done  :-DD
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5452
  • Country: fr
Re: Version Control
« Reply #115 on: April 14, 2020, 01:04:14 am »
Do not hesitate to take a look at Mercurial if you have a problem with git. Seriously.
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #116 on: April 14, 2020, 06:36:45 am »
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.
 

Online 0db

  • Regular Contributor
  • *
  • Posts: 246
  • Country: zm
Re: Version Control
« Reply #117 on: April 14, 2020, 08:06:14 am »
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.
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15527
  • Country: gb
Re: Version Control
« Reply #118 on: April 14, 2020, 08:29:34 am »
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
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: Version Control
« Reply #119 on: April 14, 2020, 08:51:39 am »
That's not going to work, because one of git's few actual design faults is you can't add an empty directory  :-DD
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15527
  • Country: gb
Re: Version Control
« Reply #120 on: April 14, 2020, 08:53:15 am »
 :palm: Still drinking my first coffee of the day.  :-DD

Add a file to each dir :)

Also, works in SVN  8)
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #121 on: April 14, 2020, 09:24:52 am »
Quote
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.
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 5139
  • Country: gb
Re: Version Control
« Reply #122 on: April 14, 2020, 01:35:21 pm »
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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15527
  • Country: gb
Re: Version Control
« Reply #123 on: April 14, 2020, 01:40:13 pm »
I've spent the last two weeks thinking that perhaps I should write something better than git. And register whateverhub.com :)
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 2011
Re: Version Control
« Reply #124 on: April 14, 2020, 02:10:01 pm »
Thanks for the advice, but...

Quote
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 :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf