Poll

What's your favorite version control system?

git
65 (62.5%)
mercurial
5 (4.8%)
svn
17 (16.3%)
cvs
1 (1%)
other
16 (15.4%)

Total Members Voted: 104

Author Topic: Version Control  (Read 3285 times)

0 Members and 1 Guest are viewing this topic.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 1492
  • 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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 4724
  • 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.

 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1728
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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 4724
  • 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.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1728
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: 1492
  • 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 »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 4724
  • 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.

 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 13659
  • 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: 1988
  • 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).
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 4724
  • 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 »
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1728
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf