EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: SiliconWizard on January 18, 2020, 03:22:45 pm
-
This poll is not meant to trigger flame wars, so please refrain ;D. Just to get an idea of the "popularity" of different VCS, tilted towards EE/embedded software development.
You can mention the one you use if you chose "other". You can also mention your reason for prefering a particular one if there is any (as long as there is no useless flaming.)
-
Dare I say Windows file history and Apple time machine?
Why not, if that fits your needs.
I've actually used a "backup" kind of version control for years before switching to a conventional VCS (first one was SVN). There was a "changelog" file maintained for each version (which I think is a good habit anyway, and I've kept it), including the "bug fix number" (third number in the traditional versioning system). We also used that in small teams, and the merging (when several people had worked on the same piece of code) was done "manually" during interactive merge sessions with all developers involved. That worked quite well and avoided a lot of the frustration you can get when fully relying on automatic merge, or manual merge that each one tends to do on their side...
Sure, you'd say that this method wouldn't scale up well for bigger teams.
Then I moved on to SVN (which was a company choice).
I've also used CVS and git, but my preferred system now (for a few years) is Mercurial. It's simple enough to fully grasp in a short time, it won't let shoot yourself in the foot like git can sometimes. It's less popular than git though, so obviously I've gotten occasional remarks that I should switch to git (even if the rationale is never clear except that it's popular), but I've found it works quite well, from individual developers to medium-sized teams.
-
SVN is on maintenance (https://subversion.apache.org/docs/release-notes/), only bugfixes and minor performance tweaks.
Mercurial is dying (https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket).
CVS, is that still around? (https://savannah.nongnu.org/news/?group=cvs).
We've made it into a git monopoly...
-
My favorite is "Save as". ;D
-
SVN is on maintenance, only bugfixes and minor performance tweaks.
I couldn't see from that page, nor any other page I browsed on that site, anything that said it was on maintenance only. (Having only fixes between feature releases isn't 'maintenance only' in this context.)
-
cvs and svn are I think completely out of the question these days. I looked forward to both when they were new and they offered huge advantages over their predecessors and I campaigned to have employers switch to them.
These days I think you would be insane to choose either of cvs or svn over mercurial or git.
I haven't used mercurial all that much. It was necessary when I was working for Mozilla back around 2010. It didn't annoy me. It didn't excite me. It seems to do the job approximately as well as git. If you're already using mercurial there might not be any compelling reasons to change.
For a new project today (or in the last ten years) I'd go with git every time. It's battle-hardened, reliable, free, and has a huge community and tools ecosystem around it.
It does pay to learn a little about git's data structure and exactly how blobs, trees, commits, and branches actually work. It's a bit like how when you're programming in C, it's an advantage to have a rough understanding of what the machine code generated from your C will look like.
Also, I avoid using a lot of options with git commands. I like to explicitly add --no-ff or --ff-only to git merge to ensure the behavior I want, and often use "git commit -m" and of course "git submodule update --recursive --init" but I'd very very rarely use any other options. I'd rather use a short series of simple no-option commands that I know I understand. Definitely be *extremely* cautious about anything with "-f". Preferably just don't do it.
And always always check what you are actually changing with "git status" and "git diff" before you commit, and definitely before you push!
If you need to merge your own branch that you've been working on for a while with a heavily changed master branch where there may be conflicts then download and learn git-imerge rather than using the built-in tools.
-
CVS is, and always was, pants. But I prefer svn over git any day. The major reason is because you have to work really really hard to screw it up, whereas with git you have to work hard NOT to screw it up (as you note!).
As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.
Also, I very often work on multiple branches at the same time. In git you work on one then switch to another, etc, or you're pushing and pulling and all sorts. In svn there's nothing like that. Commit here, work on that there, delete the entire copy... Each of those copies is just the working stuff, not the entire history of the universe replicated for each working copy. OK, you can make git more svn-alike in those respects, but it's hard work and not git-natural.
Git has benefits when multiple people are working on the same thing and effectively offline. The one thing I find git does better is let you hide intermediate local commits, but more often than not I manage to screw that up too :)
-
CVS is, and always was, pants. But I prefer svn over git any day. The major reason is because you have to work really really hard to screw it up, whereas with git you have to work hard NOT to screw it up (as you note!).
No, that's not what I said.
It's very very hard to screw anything up with git if you stick to simple commands and especially don't copy and paste overly-complicated gun-foot-bang "solutions" you find in random stack overflow answers. And don't "force" anything -- if it doesn't want to let you do it then there's a reason.
As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.
No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.
Also, I very often work on multiple branches at the same time. In git you work on one then switch to another, etc, or you're pushing and pulling and all sorts. In svn there's nothing like that. Commit here, work on that there, delete the entire copy... Each of those copies is just the working stuff, not the entire history of the universe replicated for each working copy. OK, you can make git more svn-alike in those respects, but it's hard work and not git-natural.
In git it's very easy to make multiple working directories that share the same local database. Simply do a git clone with a file reference instead of an ssh or https URL. The compressed database is just linked to, not copied.
svn keeps an entire duplicate copy of your working directory, completely uncompressed. git's "entire history of the universe" is often smaller than svn's backup snapshot, even for huge and long-lived projects such as llvm.
-
Unless you --force something or remove the .git directory or delete files that have never been committed, your data most likely still exist.
-
Git won the war. It's not the most deserving winner, but it won.
Darcs is beautiful in theory but in practice unusable for anything serious. Mercurial is a could-have-been-great contender but didn't get the critical mass. SVN had it's time in the sun, but ultimately doesn't really fit well with how development happens these days, especially in the open-source world.
If you are making an open-source software and you want other people to be able to contribute to it, it really has to be git, and more so, on github.
-
As i lately do little bit of PCB design, i wish to see better integration with git and preview tools for previous version.
That would be really great. I really have problems when i have to go back in design, when i have to keep the prototype versions and continue making changes, even before PCB arrives.
It happened few times that i lost the design and the prototype PCB arrived so i had to think deep to reconstruct what i changed.
-
As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.
No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.
Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.
I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?
-
Git won the war. It's not the most deserving winner, but it won.
Yes, no question. One doesn't have to follow the herd, though - horses for courses :)
It becomes a bit of an issue when ones tools become obsolete because they are no longer popular.
-
I'm a git convert.
SVN is on maintenance (https://subversion.apache.org/docs/release-notes/), only bugfixes and minor performance tweaks.
Mercurial is dying (https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket).
CVS, is that still around? (https://savannah.nongnu.org/news/?group=cvs).
We've made it into a git monopoly...
Not sure where you heard that about SVN, it's not "on maintenance." It's still very actively developed and highly popular, especially in corporate shops. Although git is finally starting to take over.
As a software engineer going back to the mid-80's, I've used a lot of SCM/VCS tools. SVN was my favorite for a long time, but over the last couple of years I've slowly converted to git. My team still maintains our SVN server at work, but we are pushing people to git and most prefer it now, once they get over the learning curve. SVN tends to still be more intuitive to old-timers. Newcomers who have never used anything can usually pickup git quicker, since you don't have to unlearn traditional centrally managed SCM.
And CVS isn't dead either, unfortunately. I finally shut down our corporate CVS server last year, thankfully. SVN really should have put it to rest, but there are still holdouts.
-
For examples supplied here and in other forums, I use a directory structure with one example per directory, in a parent directory per forum.
Each directory has a short README text file explaining the example (and if I remember, an URL to the relevant post).
These do not need version control per se, but since I already have hundreds of them, finding relevant ones becomes the task to speed up.
I can throw a find or grep command in a few seconds to prune the set down based on a few key words I might remember, but to verify I have the correct example without reading the README or the source code itself, I add an Usage info block to each executable, telling me what it does as succintly as I can manage. This way, I just run the executables in the candidate directories without parameters (or with -h or --help), to see if I've found the relevant example. I've found it even helps when writing the code: it outlines the needed functionality before I write it.
For development of actual projects, for version control, I too use git.
-
As i lately do little bit of PCB design, i wish to see better integration with git and preview tools for previous version.
Overall, tool vendors still need to make more effort in making their files diffable and mergeable. Eg. Altera's Qsys uses XML project files, but has many bad design decisions that make it practically impossible to compare or merge changes. For example, connections between components were based on index numbers in a list, meaning that if components were removed or inserted anywhere else than at the end, they would all break. It also had endless list of Boolean config options, represented as long arrays of "Yes,Yes,No,Yes,No". So you could see that something had changed, but no idea of what.
-
Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.
I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?
You certainly need at least one repo which never gets deleted :P
I think this problem is limited to SVN newcomers. Genuinely new users are told to create branches within repo instead of multiple repos. It is a workable approach IME; only when I really need to work on two things at a time and get tired of switching back and forth do I bother with multiple "workspaces" (still sharing the original .git directory).
As for Mercurial, I think it lost a lot by catering to noobs rather than to those who spoonfeed noobs ;)
-
As a for instance, sometimes an automated merge would go tits up (merge is much like EDA autoroute, IMO) or I would cock up something in the working copy. No problem - just delete the lot and check it out again. In git, you do that and you've lost EVERYTHING.
No, it's exactly the same in that regard. And in git you can instead simply reset your branch pointer to the commit before where you screwed it up.
Only if you've remembered to push your commit onwards to some other repo. It takes quite a while to remember that committing only commits to the local workspace, so if you delete the workspace it is all gone. In svn there is no local repo and a commit must go to some other place, thus deleting the workspace if not a problem.
I wonder how many users (probably new ones) don't bother to make a 'local central' commit-only repo to prevent that kind of thing happening. And in doing so, haven't they just done what svn does but a longer way around and non-native?
One of the main reason at the company we switched to svn from git. besides all the EEs used svn before, and most git features were: "Why would I ever do that?" It fits better, because you have an actual version number, that you can print on schematic, or write into documentation. It also handles binary files better. Our sysadmin was mortified, when we told him we commit tens of MB large binary files to git.
For coding, git is probably fine, and could make more sense.
-
because you have an actual version number
oh, don't get me started on version numbers!
No, go on then. How do you implement automatic version numbering such that a later commit is clearly a larger number? The aim of the game is to take this version and that version and be able to say, without perusing logs or charts or anything else, that version B is derived from version A rather than vice versa. (A timestamp would do it were it not far too long.)
-
It also handles binary files better. Our sysadmin was mortified, when we told him we commit tens of MB large binary files to git.
That's just wrong. git treats *all* files as binary. It handles large binary files such as disk images or databases, or image formats such as BMP or uncompressed TIFF, or even program binaries just fine, storing only the minimal differences between different versions.
What git doesn't handle is file formats where any tiny change results in almost every bit in the file being different, such as encrypted or already-compressed files.
-
I use Fossil for personal projects: https://fossil-scm.org/home/doc/trunk/www/index.wiki
It's written by Richard D Hipp of SQLite fame and is absolutely bomb proof.
Git is just horrid but at work it's the standard tool so I have to suck it up. :(
-
because you have an actual version number
oh, don't get me started on version numbers!
No, go on then. How do you implement automatic version numbering such that a later commit is clearly a larger number? The aim of the game is to take this version and that version and be able to say, without perusing logs or charts or anything else, that version B is derived from version A rather than vice versa. (A timestamp would do it were it not far too long.)
Version control systems don't actually provide version numbers for humans. They just provide an identification of a particular state.
For version numbers you have to do something else. Such as https://semver.org/
-
Voted 'other' because: my favourite VCS of those listed would be mercurial but a need to collaborate with lesser morals means that git is the most used for me.
Edited to add: I too have been contemplating switching to fossil for personal work.
-
Version control systems don't actually provide ...
My choice of words wasn't great :)
I am not asking about how to identify a version in relation to features, etc. That's a separate thing and, typically, manually sorted out. What I am asking is if I'm presented with two version numbers which both have the same semantic numbering IDs, how I can tell which is the newer one. In subversion the last field of the version number typically shows the commit reference, so that's easy. Also gives a small clue as to how far apart they are in changes. And also whether version X is actually version X or version X modified.
That isn't something svn implements, as I'm sure you know but I should state just to be clear. It is an external util that extracts the build reference and does whatever needs doing. It is a stunningly useful thing to have and I've not found a way of achieving the same using git. Hence my question.
-
I am not asking about how to identify a version in relation to features, etc. That's a separate thing and, typically, manually sorted out. What I am asking is if I'm presented with two version numbers which both have the same semantic numbering IDs, how I can tell which is the newer one. In subversion the last field of the version number typically shows the commit reference, so that's easy. Also gives a small clue as to how far apart they are in changes. And also whether version X is actually version X or version X modified.
You can use something like "git rev-list --count" to get the number of commits on the current branch, but that is something that is IMO better done by having eg. the build system inject the build number.
-
"git rev-list --count" to get the number of commits on the current branch
That might be doable, thanks :)
the build system inject the build number
What is the build number is this context?
-
"git rev-list --count" to get the number of commits on the current branch
That might be doable, thanks :)
Ah, no it isn't, I think. The commit count isn't immutable or unique, ISTR, so you might as well make up a number. The commit reference in svn isn't immutable, but it takes quite a bit of effort to change it and I think I've only ever needed to do it once.
-
The commit count isn't immutable or unique, ISTR, so you might as well make up a number.
Exactly. If you need to uniquely identify the commit, you need the hash. If you just want a monotonic counter, have the build system provide one. The build server can then automatically tag the commit with the build number, providing the backwards mapping. In practice, rewriting published history is rare, and can be blocked in most repository hosting servers.
Just to state the obvious, just the commit number doesn't imply a relationship in any version control system, you need to include at least the branch name as well.
-
I disagree with the build system providing this. Only because I've watched people trying to do it right for 20 years and failing miserably. This culminated in the turd that is semantic versioning which is almost always universally poorly implemented and of no use whatsoever to the end user or any internal team past the desire to add complexity. Look back in the past and ask yourself, "does major version matter?". Eventually only the release version matters and that just has to be greater than the last release version. Add poorly implemented or NIH libraries to manage this and it's a world of hell. Imagine a piece of shit written in Groovy embedded in Jenkins by someone who left 2 years ago steaming away with a thousand edge cases waiting to blow. That's reality and it sucks.
You should never rewrite history. Git provides a lot of nasty stuff like that such as squash merges which it pretends is nothing to do with rewriting history but it is exactly and it's absolutely impossible to go back and blame who the hell did X, Y or Z and that is absolutely essential for audit.
A lot of people complain about Subversion but honestly it's probably the best solution out there still for large teams. The tools are good and understandable by mere mortals, the thing can have decent single-sign-on authentication without a ton of infrastructure, it's append only as far as the end user is concerned and every commit already has a monotonic incrementing ID. Now I'm going to get a "wait a minute, what about untracked merges" complaint here but that was never actually a problem because you can still epically fuck up any large codebase with merges using exactly the same method in git and incur exactly the same cost. Where people are doing work is a human issue. You can't have two teams refuctoring (misspelled intentionally) the same code regardless of the VCS. You are at the mercy of logical intent and diff not the VCS so stop pointing fingers at it.
I'm not even getting into the horrid side of git as well such as storing binary content or product composition, which by nature of it forces you to use external piles of crap like Artifactory and being bled dry by infrastructure software. Adding complexity to software delivery never results in any cost benefit.
I regularly work with 203 github repos, 40 MLOC of code and 160 engineers and it's a nightmare when you want to scale up a team like that.
Ergo for me:
Single user: learn and use Fossil.
Small team: One subversion repo for all projects. Lightweight branches.
Large team: lots of subversion repositories. Software composition via repo links. Light branches per repository.
really skilled team (rare): learn and use fossil.
Edit: mini rant on github. No one actually knows how to use git anyway. Teams should push upstream and then someone composes the product (think Linus and kernel etc) then that is published after it has gone through various pipelines. Every stage has their own repository and code flows between. But no along came some idiots and puked a pile of ruby into the universe which removes the distributed property of the entire VCS, which is its only benefit, and everyone starts circling that like flies around shit. It's wrong, broken and utterly stupid.
-
You should never rewrite history. Git provides a lot of nasty stuff like that such as squash merges which it pretends is nothing to do with rewriting history but it is exactly and it's absolutely impossible to go back and blame who the hell did X, Y or Z and that is absolutely essential for audit.
I have worked with certain individuals - no names, no pack drill - where the quickest way of sorting out a bug in a bit of code was to run git 'blame' and find out what 'Fred' had touched recently.
-
You may have worked with me :-DD
Edit: it's interesting when you get audited and the nice report from one of the top tier security companies lands on your desk with a question "when did X regress and who did it?". "err sorry that was git squashed out of existence" is not the answer that people want to hear.
That's almost as horrid as the NHS lot using their smart cards to log their colleagues in.
-
You may have worked with me :-DD
I know it's not you as I know you well enough to know that you're not Welsh/German/Hungarian/South African, which nationalities describe the particular bête noire I had in mind at the time. :)
-
Ah yes. I am a master insults in Afrikaans these days. Comes with the territory!
-
Version control systems don't actually provide version numbers for humans. They just provide an identification of a particular state.
For version numbers you have to do something else. Such as https://semver.org/
Versioning systems like semver was designed primarily for libraries or components and mostly to make package managers enough robust. Simple build number is more natural for standalone projects. You can relay on build system to keep this number actual but human readable change id from version control is much better there. This isn't possible with git but I personally don't see a big issue there. Just a few extra steps that are easy to automate.
-
because you have an actual version number
oh, don't get me started on version numbers!
No, go on then. How do you implement automatic version numbering such that a later commit is clearly a larger number? The aim of the game is to take this version and that version and be able to say, without perusing logs or charts or anything else, that version B is derived from version A rather than vice versa. (A timestamp would do it were it not far too long.)
SVN, you commit something, number increases. Your coworker commits something, number increases. It doesnt have to be more complicated than that.
It also handles binary files better. Our sysadmin was mortified, when we told him we commit tens of MB large binary files to git.
That's just wrong. git treats *all* files as binary. It handles large binary files such as disk images or databases, or image formats such as BMP or uncompressed TIFF, or even program binaries just fine, storing only the minimal differences between different versions.
What git doesn't handle is file formats where any tiny change results in almost every bit in the file being different, such as encrypted or already-compressed files.
So git doesnt work well with Altium files, STEP files and other 3D stuff, drawings like PDF, or documentation in MS office. Most of the stuff we do. It handles TXT files well.
Not to mention this " you have to pull the entire repo before push, whoopse doda tree conflict" was just driving us nuts. Also, you cannot commit an empty folder?
-
I sorta like RCS for its simplicity, for source code and single-person projects.It's not good for binary files, or modern web-based storage. I use git mostly, but mostly just because github...
-
So git doesnt work well with Altium files, STEP files and other 3D stuff, drawings like PDF, or documentation in MS office. Most of the stuff we do.
And neither will any incremental backup system. BOOM! Whole file duplicated every time.
I'd say it's bad design of those file formats.
PDF would be pretty ok if it didn't have internal compression. Similarly, modern MS Office XML documents would be fine if they weren't then compressed.
-
Rdiff-backup does binary file diffs....
-
Rdiff-backup does binary file diffs....
Yes, and files that git can't do compact diffs on because small changes cause every bit to change, rdiff-backup won't be able to either...
-
And? Storage is cheap!
-
If Git is good enough for the Linux kernel source, it's definitely good enough for my purposes...
-
The linux kernel used to be SVN... They made their own since nothing else fit the requirements of a large project.
Should say something about what was available.
-
Actually they built their own because they used Bitkeeper and there were constant flamewars between the owner of Bitkeeper and Linux maintainers. It was a grand "fuck you" basically.
(https://imgur.com/WG0HmUv.jpg)
-
Yes, but the picture is wrong. (and was aimed at nvidia)
https://en.wikipedia.org/wiki/BitKeeper#Pricing_change (https://en.wikipedia.org/wiki/BitKeeper#Pricing_change)
https://web.archive.org/web/20070929115009/http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481 (https://web.archive.org/web/20070929115009/http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481)
Looks like they changed their minds though, they are on Apache 2.0 now.
-
Yeah that's just Linus' attitude.
RMS complained, then Larry at bitseeker got the ass then it got fixed: https://marc.info/?l=linux-kernel&m=103457829307456&w=2
Bitkeeper is dead.
I love Linux flamewars! :-DD
-
Maybe I'm thick,
Grrrr. Turns out I am :(
-
And? Storage is cheap!
Storage is cheap as in I don't mind if some 100 MB file is stored uncompressed in my working directory instead of being compressed to 20 MB or 50 MB, if that means that when I change a few bytes of that file only a few bytes are added to the repo and only a few bytes are transmitted to the central repo and to other users.
I don't want the file to be compressed to 20 MB or 50 MB in my working directory if it means that every time I make some tiny change (which might be hundreds or even thousands of times) my repo grows by 20 MB or 50 MB and that amount of data has to be transmitted to the central repo and to other users. Storage isn't *that* cheap.
-
Actually they built their own because they used Bitkeeper and there were constant flamewars between the owner of Bitkeeper and Linux maintainers. It was a grand "fuck you" basically.
I would hope that people on an AUSTRALIAN bbs would remember the real story!
Linus was perfectly happy with bitkeeper and the restrictions his friend Larry McVoy put on open-source use of it. It was Aussie Tridge who was not happy with having to use a proprietary tool to access Linux kernel sources and reverse-engineered (or perhaps just used the available documentation) the wire protocol to create the open source SourcePuller tool.
The biggest fight was between Torvalds and Tridgell, with Linus accusing Andrew of being a wrecker who didn't create anything new, such as a better source code control system, but simply come in an destroy the arrangement he'd made with McVoy.
See for example https://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/ (https://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/)
-
I don't want the file to be compressed to 20 MB or 50 MB in my working directory if it means that every time I make some tiny change (which might be hundreds or even thousands of times) my repo grows by 20 MB or 50 MB and that amount of data has to be transmitted to the central repo and to other users. Storage isn't *that* cheap.
Storage is that cheap nowadays, what isn't cheap is bandwidth multiplied by the number of people involved. That's why people moan when some chump links in several 25 Mb images to a post here - the individual cost is annoying, the cost multiplied by the number of people involved is irresponsible.
Anyway, version control systems really aren't about versioning the outputs (e.g. binaries) from a project, they're about versioning the inputs. If people complain about version control systems that behave badly because someone chose poor inputs that have to be stored in binary forms that are highly labile with small changes then surely the finger needs pointing at the latter not the version control system.
-
Tech Talk: Linus Torvalds on Git:
https://www.youtube.com/watch?v=4XpnKHJAok8 (https://www.youtube.com/watch?v=4XpnKHJAok8)
-
Anyway, version control systems really aren't about versioning the outputs (e.g. binaries) from a project, they're about versioning the inputs. If people complain about version control systems that behave badly because someone chose poor inputs that have to be stored in binary forms that are highly labile with small changes then surely the finger needs pointing at the latter not the version control system.
That is my point exactly.
git handles binary file formats where a small change by the user results in a small number of bytes changed in the file just fine.
-
The crows of people who haven't tried dealing with and merging a 400Mb JSON or XML file :-DD
"but it's a text format"
Hmm... give me it in a zip thanks.
-
Single user: learn and use Fossil.
Small team: One subversion repo for all projects. Lightweight branches.
Large team: lots of subversion repositories. Software composition via repo links. Light branches per repository.
really skilled team (rare): learn and use fossil.
Now there is a breath of fresh air!
I'd be a millionaire Fossil user if I had a dollar for every time I've read the following:
"I use GIT because :-* :-* :-* GITHUB :-* :-* :-*"
or
"I use GIT because if it's good enough for the Linux kernel, then it's good enough for my Arduino * project"
* Today's trivia, there are 56 "arduino cat feeder" projects on Github and zero on Sourceforge.
-
.... Just to get an idea of the "popularity" of different VCS, ...
Sorry, I didn't vote since the question mentioned 'What's your favorite version control system?' Unfortunately, I don't have one.
I stopped use svn while ago, basically once a laptop become as one of primary tools.
git is okay for most of stuff these days, except some c******f**k happened with git-lfs... :palm:
fossil looks very promising and I like idea all-in-one. :-+
still on a mission to find out how to manage binary assets :-//
-
I stick large binaries in amazon S3. You can enable bucket versioning.
-
Sounds terrible! I still have nightmares about Word documents with links to diagrams instead of embedded stuff, then finding out at the worst possible moment the linked-to folder no longer exists. Or some git (ho ho) sent me a document with links to their local filesystem. Always embedded everything since then :)
-
Sounds terrible! I still have nightmares about Word documents with links to diagrams instead of embedded stuff, then finding out at the worst possible moment the linked-to folder no longer exists. Or some git (ho ho) sent me a document with links to their local filesystem. Always embedded everything since then :)
I know, it's called "Portable Document Format". It's the only format that makes sure it looks the same everywhere. For sure no office shit.
-
Yep. LaTeX in PDF out.
-
Single user: learn and use Git
Small team: Git.
Large team: Git.
really skilled team (rare): learn and use Git.
>:D
-
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.
-
Yeah. No private branching? No rebase?
Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?
-
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.
I don't know about those "charlatans" you are talking about.
I believe Linus when he says it outperforms all alternatives, wether it is price, speed, flexibility or integrity.
If I have to choose to believe you or Linus, I choose Linus
(no offence, I have high regards of you and most of the time I appreciate/agree what you are writing here).
-
Yeah. No private branching? No rebase?
Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?
fossil commit --private ?
Such a broken process. Bisect uses a binary search so you need a source of truth that says "yes that build did X" so the scope of effort is minimally T*O(log N) where N is commit span and T is the average build time. That can't be improved upon. But bisect is last resort in the middle of a shitty process. If you have to use bisect you fucked up somewhere already. I mean for example the RTT build time to integrate the current product I'm working on is around 4 hours. Do you have time to bisect that when there's a regression? Nope! You better have some skills and some history available.
But nope, you squashed it and that erases whodunnit and whendunnit in the process and only tells you who merged it to master. That's fine until you get malicious user or a nasty compliance question to answer. You're purposely erasing history.
I expand my comment to "people don't know how to manage software properly".
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.
I don't know about those "charlatans" you are talking about.
I believe Linus when he says it outperforms all alternatives, wether it is price, speed, flexibility or integrity.
If I have to choose to believe you or Linus, I choose Linus
(no offence, I have high regards of you and most of the time I appreciate/agree what you are writing here).
They are charlatans. "a person falsely claiming to have a special knowledge or skill.". I've watched several "git experts" hit a wall pretty hard and that is almost always when everyone is wading up to their knees in shit at the time.
Linus sits in a monoculture. He's a kernel developer. He's a technical expert. He has a tightly controlled team. It works for him. It works for the Linux kernel. On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are! So all is not good in the house of git. It's a mess of hypocrisy at best. A cargo cult. At the core it works for the use case it was designed for but have you tried sending patches by email to upstreams users in git? Oooh that's a world of hell.
On top of that despite the massive ego, he really doesn't speak for the vast and disparate set of teams out there which range from graphic designers who want to just frig some CSS in a project to people up to their eyes in threading bugs inside event reactors in trading systems, delivering large enterprise software behemoths with a thousand dependencies. What matters there is the process, the controls, the methodology and the outcome. What we tend not to want is tools with a thousand foot guns built in that can span a reasonable set of use cases.
Git has a high cost in these environments and those environments are far far far far more common than the world that Linus speaks of.
https://ohshitgit.com/ is a fine example of the disparity between the user and the knowledge required to run git.
Edit: Incidentally I'm paid to shut up and use it. But not my funeral!
-
Yeah. No private branching? No rebase?
Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?
A rebase is just a merge that forgets where it came from ...
https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md (https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md)
https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki (https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki)
-
On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are!
I was talking about Git, not github (which I left almost the same day microsoft bought it).
I think we agree about Git != github.
-
Bisect is standard process in projects which take a few minutes tops to incrementally recompile, and there is many such projects. If the project maintains a "no untested commits on master" policy (and anyone serious does), bisect is quick and can easily be done by any intern, monkey, sometimes even the customer, and it neatly nails the regression down to a single commit.
In a properly managed git repository the commits aren't "merge XYZ and forget where it came from". You split them into logical series after the complete implementation has been worked out, along the lines of:
1. prepare X to accept new Y
2. update Y
3. expand Z to use new X and Y functionality
It seems that with fossil, I would be forced to bisect between meaningless mammoth merge commits and then descend into a hairy development branch which truthfully reflect the development process, i.e. bugs, non-building revisions, dead ends, reverts...
There is nothing preventing you from having a policy to preserve those branches in git, although in practice few do. I tend to keep them on my own machine even if the employer doesn't care.
If you use gerrit, all the development history is kept by gerrit, complete with code review, discussion, everything. But you don't need to look into that garbage if you are just viewing the changelog or bisecting.
Don't post me links to fossil website. I just came back from there and that's why I rant :-DD
-
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
That doesn't make sense.
The longer the project takes to build, the *more* valuable bisect is relative to backing up one commit at a time to find the problem.
-
Bisect is standard process in projects which take a few minutes tops to incrementally recompile, and there is many such projects. If the project maintains a "no untested commits on master" policy (and anyone serious does), bisect is quick and can easily be done by any intern, monkey, sometimes even the customer, and it neatly nails the regression down to a single commit.
In a properly managed git repository the commits aren't "merge XYZ and forget where it came from". You split them into logical series after the complete implementation has been worked out, along the lines of:
1. prepare X to accept new Y
2. update Y
3. expand Z to use new X and Y functionality
It seems that with fossil, I would be forced to bisect between meaningless mammoth merge commits and then descend into a hairy development branch which truthfully reflect the development process, i.e. bugs, non-building revisions, dead ends, reverts...
There is nothing preventing you from having a policy to preserve those branches in git, although in practice few do. I tend to keep them on my own machine even if the employer doesn't care.
If you use gerrit, all the development history is kept by gerrit, complete with code review, discussion, everything. But you don't need to look into that garbage if you are just viewing the changelog or bisecting.
Don't post me links to fossil website. I just came back from there and that's why I rant :-DD
Now I'm confused .....
Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT, or are you ranting because your emotive laden anti Fossil diatribe "meaningless mammoth merge ... hairy development branch ... " (whilst impressively demonstrating initiative and flair for fud creation), really isn't doing anything to make Fossil appear lacking compared to GIT ?
I know !!!
It's because the Fossil inbuilt help only takes 61 lines to explain the use of BISECT, compared to the 434 lines it takes GIT ? :-DD
GIT ... what SCM task would you like to obfuscate today ?
-
On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are!
I was talking about Git, not github (which I left almost the same day microsoft bought it).
I think we agree about Git != github.
I think bd139 is still making a very good point. A large number of git users (whether they are using github or another platform) are in fact using git more as a centralized system than anything else, which is not what git was meant to be about, and which means that many just use git because it's popular, not because of its intrinsic qualities.
I'll make some kind of summary/comment of the results and what has been discussed here when we reach ~100 votes.
-
A big plus for git (and svn) over the likes of fossil is Tortoisegit/svn/hg on Windows. Worth every penny.
-
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
That doesn't make sense.
I was responding to the case when build takes so long that you would rather comb through changelogs than spend a week bisecting.
Now I'm confused .....
Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT
I think it's the latter. I'm literally shaking and triggered by their insistence on preserving accurate history over creating a fake one which is convenient to review and debug ;D
-
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
That doesn't make sense.
I was responding to the case when build takes so long that you would rather comb through changelogs than spend a week bisecting.
bd139 quoted a 4 hour build time as not being worth bisecting.
A week of bisecting with a 4 hour build time lets you find the one bad commit in the last 2^42 = 4,398,046,511,104 commits.
That's a lot of changelogs to comb through.
-
It's far far easier to write a test case, see what explodes then use the repo blame function rather than sit and wait a week on a 4 hour build.
That's got an aggregate faster turnaround if the MTTR and SLO requirements are fast turn around which they usually are.
People use the wrong tools all the time.
-
It's far far easier to write a test case, see what explodes then use the repo blame function rather than sit and wait a week on a 4 hour build.
And of course that's what you do for 90% or 95% of bugs.
But there's the other 5%...
-
Now I'm confused .....
Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT
I think it's the latter. I'm literally shaking and triggered by their insistence on preserving accurate history over creating a fake one which is convenient to review and debug ;D
I sympathize completely and I'd send you a nice cuddly stuffed Fossil mascot to hug in your safe space if I could :-+
I can only imagine your anger as you read thru the Fossil treatise on REBASING and encountered statements such as "Rebasing is the same as lying" or "Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative."
What's really scary is the possibility that one day GIT might fix their weak history display capabilities and give their users the ability to switch back and forth between those instances where a simplified display is desirable and edifying and one showing the real, complete, messy history for cases where detail and accuracy are more important ?
My opinions only and you know I always enjoy your posts :)
-
You might want to use svn for that :-DD
-
I'll make some kind of summary/comment of the results and what has been discussed here when we reach ~100 votes.
That could be a while, or never because it's looking like only 60 - 70 posters among the hundreds of thousands on this forum actually use a SCM.
To most Github users, I suspect GIT is just a downloader.
-
Perforce
-
I wonder how fossil fanboys do review?
Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.
And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P
-
Not a fan boy (only briefly looked at it) but my understanding is that if you really want the compressed version you can allow that. It's just that the whole truth version is still there if someone cares to look at it - it can't be actually removed, just hidden.
-
I wonder how fossil fanboys do review?
Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.
And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P
Code review is a human issue. No tool is any good there despite the marketing. I know that because I’ve watched people hand jobbing each other’s PR’s through because they share a pint after work occasionally. I’ve watched people miss some pretty obvious shit. My favourite being the one where there was a non terminal loop iterating through dates which took out 45 production machines running 50 threads each in under twenty seconds from deployment and caused a massive SLA pay out. All because a dingbat was a bit hung over that day.
And then there’s the issue of the size or scope of a change. When that rebased and squashed PR for a feature branch comes in at 20,000 LOC no one is going to give a shit about it. Flag it through like the chequered flag at the end of a Grand Prix.
And on top of that does anyone know enough about what they’re doing to rationalise every decision made? They need to know the business domain and the programming language and the entire system well for this to be productive.
Ergo we have to ask should we even bother?
Yes we should but don’t formalise it. Drag a random colleague over and sit down and go through it together in person on your branch. Push it to someone else to get feedback on the other side of the planet. Get a QA guy to have a look at your branch. Get the build system and full integration test feedback in your branch (you are building your branches in your CI/CD platform aren’t you?). Once confidence is attained, then merge it and deploy it.
None of that is VCS or product specific.
What is the value of a PR? Near nothing.
I find it’s better to review the humans. Good programmers do the above implicitly and self organise.
Edit: for ref I was the dingbat who left the non terminal loop and it was flagged through by someone who actually accepted the review 11 seconds after I opened the PR...
-
And? Storage is cheap!
Really? You never met guys who estimated a low 5 digital expense in Excel that will last decade or so in AWS, but a recent bill in mid-6 figures "shock the nation"? >:D
-
And? Storage is cheap!
Really? You never met guys who estimated a low 5 digital expense in Excel that will last decade or so in AWS, but a recent bill in mid-6 figures "shock the nation"? >:D
Aka Thursday for me :-DD. It’s not about saving money but shifting capex to opex. No one has worked that out yet.
-
I stick large binaries in amazon S3. You can enable bucket versioning.
How big your "large binaries" and a link to AWS?
I only put a public stuff and works fine with CloudFront.
The versioning save my a** a few times after mess I did there. :-+
-
I wonder how fossil fanboys do review?
Say I'm supposed to review a feature to be merged into master. In the usual git-liar workflow, I get a pull request with a bunch of commits which implement the feature in logical steps. I can understand what each commit does, analyze it in isolation, verify that the software builds and works between the commits so no breakage will occur if somebody runs bisect in the future.
And without lying? You guys want me to review the whole branch, including commits like "fix a typo which broke the build" and "address the remarks of Johny Grammar Nazi"? Or maybe look at the Big Diff and try to make sense of all of it? I think I would rather be lied to :P
Fanboys ?
The Tcl/Tk project uses Fossil, and it's a rather large project with a decent-sized community, I suppose they manage reviews one way or another ?
http://core.tcl.tk/tk/timeline?y=ci (http://core.tcl.tk/tk/timeline?y=ci)
[attachimg=1]
-
I stick large binaries in amazon S3. You can enable bucket versioning.
How big your "large binaries" and a link to AWS?
I only put a public stuff and works fine with CloudFront.
The versioning save my a** a few times after mess I did there. :-+
Dependencies ~400Mb a go. VM images 8-20Gb a go. Link varies. I’m happy on 76mbits down
-
The Tcl/Tk project
TIL that Tcl/Tk still exists!
Seriously I thought that would be deader than CVS at this point!
-
I stick large binaries in amazon S3. You can enable bucket versioning.
Doesn't that (bucket versioning) essentially convert git/svn/fossil or whatever back to VCS badness, specifically file versioning as opposed to project versioning? That is, to go back to version n you need version n of the locally held files plus version m of the bucketed files.
-
Yeah that's just Linus' attitude.
Showing Nvidia, who treated Linux as second-class citizen, the finger got him then lot of sympathy. And it seemed to have helped.
RMS complained, then Larry at bitseeker got the ass then it got fixed: https://marc.info/?l=linux-kernel&m=103457829307456&w=2
Bitkeeper is dead.
Not sure what you mean by 'dead' there. I don't know how viable Larry's business is, but they're still getting pretty a penny from the company I work for (support contract -- the actual software is FOSS now). We're using it since the code base is old, quite large and getting it (and more importantly the history of code changes) into git was deemed impractical and not worth the effort a few years back. Most of the engineers would probably be content using git, but some swear by bitkeeper. At the very least, we had little trouble with it and Larry (regardless of his reputation otherwise) has been very responsive and competent in the few cases there were questions.
I love Linux flamewars! :-DD
So much that you attempt to start one with half-truth and out-of-context quotations?
-
Linus’ attitude generally is consistent with that photo. I know the context. It was intended to show the attitude. I mean have you seen the outbursts on LKML?
Bitkeeper is dead. It’s a niche product eaten by momentum. 99% of people I have worked with have never heard of it. Compare Perforce and RCS which are known universally. Even if the latter is dead.
So half truths, no. Out of context, no.
I stick large binaries in amazon S3. You can enable bucket versioning.
Doesn't that (bucket versioning) essentially convert git/svn/fossil or whatever back to VCS badness, specifically file versioning as opposed to project versioning? That is, to go back to version n you need version n of the locally held files plus version m of the bucketed files.
Depends on your workflow. If you have to version large binaries (Gb in size) I haven’t found a better option.
-
I wonder how many people use AllChange, which I was forced to use recently. It wasn't designed specifically for software, and naturally it's a real pain in the ass to use.
-
Seen that. That's plainly aimed at upper management not end users
-
So i searched what GIT is and found out it is a software-application where in you save your source codes ?
ha ha ha
-
So i searched what GIT is and found out it is a software-application where in you save your source codes ?
ha ha ha
That's a joke right...? :-//
-
I'm personally a fan of git, but for developers using windows, I think subversion is attractive.
-
I am intrigued! Why would Windows make subversion more attractive than git?
-
TortoiseSVN. UI that isn't shit and mortals can operate.
I slightly hoped this thread had died. Oh well. :-DD
-
But there is Tortoisegit, and TortoiseHg.
-
I have always tried to be careful about data structures in programs in regards version control.
I tend to leave a few empty spaces in the structures in case i need to add more later on.
The empty items are always zeroed on creation to ensure they are initialised.
Another thing I do is if I really have to add a variable it is saved to disc in its own file rather than mess with files already there.
When it was impossible to do anything else but add a new structure I have always added a "legacy update" function for it so newer versions of software can convert older versions.
This means i tend not to keep old versions of the software.
I have used GIT a couple of times but never found a reason to get the old versions back.
So what is more important to me is not losing any data and so I carefully back up to back drive, flash drives and DVD's.
I keep one flash drive in the car in case of fire.
-
I slightly hoped this thread had died.
Well, the voting part is definitely :=\, but hearing from others their preferred workflow is definitely interesting.
-
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.
-
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.
-
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.
-
I mean to say 'unadventurously' :) Speling cheker got to it :(
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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!"
-
I just send the https://ohshitgit.com and job done :-DD
-
Do not hesitate to take a look at Mercurial if you have a problem with git. Seriously.
-
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.
-
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.
-
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
-
That's not going to work, because one of git's few actual design faults is you can't add an empty directory :-DD
-
:palm: Still drinking my first coffee of the day. :-DD
Add a file to each dir :)
Also, works in SVN 8)
-
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.
-
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.
-
I've spent the last two weeks thinking that perhaps I should write something better than git. And register whateverhub.com :)
-
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 :)
-
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.
-
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.
You can use git for accessing code that's on git, and use something else for your own projects.
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.
Never had a problem with that.
Usually that wouldn't bother me because I rarely use the built-in stuff anyway,
Ditto.
but it's an indicator of industry support and I've been bitten previously by jumping ship to something that gets binned shortly afterwards.
I understand the point, but I don't subscribe to it.
First thing is, don't worry too much about the tool being binned. Mercurial has been around for (slightly) longer than git actually, and is still actively maintained. As it's used by a few big organizations (such as Mozilla), I doubt it will get abandoned any time soon.
Anyway, do as you wish - I'm not evangelizing - just suggesting something that has worked for me quite well and that I think is worth considering, rather than sticking to something like git that may be popular but (as a few of you also said) has a number of flaws that can make it annoying to use, or even a nightmare in some cases. Sometimes popularity doesn't imply quality.
To add to the oddities of git, something annoying I have noticed (please tell if that happens to you as well): like you, I use it occasionally to pull third-party code. Every once in a while, a "git pull" will result in conflicts (that you have no idea about) whereas you have modified absolutely NOTHING in your local repo. It's fucking annoying, and looks like the tool sometimes can't even agree with itself. Anyway.
-
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 :)
Having a reasonable number of submodules for truly independent things with well-defined and stable interfaces between them works perfectly reasonably. You just have a master repo for each submodule -- which can be the local bare repo you made, but one for each submodule -- and then just step into each submodule and push it. You can copy the commands needed into a little script, if you want.
See for example something like https://github.com/riscv/riscv-gnu-toolchain which is a repo that consists almost completely of seven major submodules. In my experience it works fine.
Some projects do go overboard with submodules. One I love to hate is Android, which has dozens and dozens of git submodules. At least they wrote a tool ("repo") to help with this, but it's still a pain.
It sounds as if whoever set up your software similarly went overboard with submodules.
Maybe repo would help you: https://gerrit.googlesource.com/git-repo/
-
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.
I don't find that to be true at all.
git uses some different concepts to other version control software but it is very simple at heart and it's well worth making a little bit of effort to understand the main points of the structure.
I've never come across a git bug that loses data in a repo. The 100% always reason for loss of data is user error, especially user error in copying and pasting commands that use the "force" option from some well-intentioned colleague or internet site. Don't do that!
Sadly, many of the git commands have grown a lot of obscure options over the years. It's almost never necessary to use them or learn them. You can accomplish exactly the same thing using a short sequence of much simpler commands, each of which you *do* understand.
Don't expect to find a canned solution for every situation. git is a version control toolkit for use by programmers. It is not and never will be a 100% finished and highly polished walled garden of version control.
-
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.
I don't find that to be true at all.
git uses some different concepts to other version control software but it is very simple at heart and it's well worth making a little bit of effort to understand the main points of the structure.
I've never come across a git bug that loses data in a repo. The 100% always reason for loss of data is user error, especially user error in copying and pasting commands that use the "force" option from some well-intentioned colleague or internet site. Don't do that!
Sadly, many of the git commands have grown a lot of obscure options over the years. It's almost never necessary to use them or learn them. You can accomplish exactly the same thing using a short sequence of much simpler commands, each of which you *do* understand.
Don't expect to find a canned solution for every situation. git is a version control toolkit for use by programmers. It is not and never will be a 100% finished and highly polished walled garden of version control.
No, git is a version control toolkit for Linus Torvalds. I've seen it blow up in lots of people's faces. The claim that git has never lost data due to a bug is probably true, but only strictly true. As you point out git will happily trash your universe if you ask it to, and it makes it so easy to ask it to. The very fact that you have to use a series of hard to remember commands and options to accomplish what ought to be smooth and simple is what damns git - e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up. Check BD139's reference to ohshitgit.com for all the common use cases that would have been designed into a well crafted version control system.
Your last paragraph, frankly, just comes over as patronising. There was us thinking that it was a version control system for kindergarden teachers, silly us.
-
As you point out git will happily trash your universe if you ask it to, and it makes it so easy to ask it to.
If I was the boss of git I would remove all --force options. Sadly I'm not, but I can and do strongly recommend that you don't *use* them -- and certainly not on a repo that other people have access to.
The very fact that you have to use a series of hard to remember commands and options to accomplish what ought to be smooth and simple is what damns git
My point, which I stand by, is that a series of easy to remember and understand commands is sufficient.
e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up.
Stop right there.
You're right. You've screwed up. Git is designed to be (and is) a faithful and non-forgeable record of the history of a project, mistakes and bugs and all.
Pushing a spur of the moment change to the master branch of a public repo without reflection, testing, and preferably review is more than somewhat unprofessional.
Force pushing a fix to pretend it never happened is simply terrorism.
Even if it is only 30 seconds, on a busy project someone else may already have pulled, and then your force-push screws them *totally*. Just don't do it. Own your screw up and push the fix on top of it.
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
There is logically no smooth and simple and invisible recovery from this situation in a public repo. Other revision control systems such as svn don't let you even pretend there is. As I said, git should arguably not have the force option available on commands, and certainly not on push. We can't change that now, but we *can* tell people DON'T USE IT.
If you don't want to have careless screw-ups and subsequent fixes in the public permanent record then don't put them there. Git has plenty of mechanisms to help you avoid them, such as local and public feature branches and reordering and combining commits as you copy them from one branch to another, and then finally merging tested a reviewed changes to master.
This is something that git supports a thousand times better than svn or cvs or others.
-
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
That's "very open source of you" to point out.
I prefer the analogy of an American car. It's fine if you drive it in a straight line. But the moment you get to an unexpected corner it tumbles off the road, catches fire and incinerates the occupants.
As Cerebus says it's designed for Linus. In fact it actually works pretty well for the kernel team set of use cases and working model. But the thing is absolutely no one uses it like that at all. They use it like SVN centralised on github. On top of that there are several workflow cargo cults such as gitflow who managed to attract a lot of the perhaps all too usual fashion victims in the software sector.
This leads to several terrible outcomes on a regular basis especially when you have medium sized teams. For reference, this is the scale of our world of hell. There are at least 5 people completely broken 100% of the time.
(https://imgur.com/fgFhY0h.jpg)
-
e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up.
Stop right there.
You're right. You've screwed up. Git is designed to be (and is) a faithful and non-forgeable record of the history of a project, mistakes and bugs and all.
Pushing a spur of the moment change to the master branch of a public repo without reflection, testing, and preferably review is more than somewhat unprofessional.
Force pushing a fix to pretend it never happened is simply terrorism.
Even if it is only 30 seconds, on a busy project someone else may already have pulled, and then your force-push screws them *totally*. Just don't do it. Own your screw up and push the fix on top of it.
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
There is logically no smooth and simple and invisible recovery from this situation in a public repo. Other revision control systems such as svn don't let you even pretend there is. As I said, git should arguably not have the force option available on commands, and certainly not on push. We can't change that now, but we *can* tell people DON'T USE IT.
If you don't want to have careless screw-ups and subsequent fixes in the public permanent record then don't put them there. Git has plenty of mechanisms to help you avoid them, such as local and public feature branches and reordering and combining commits as you copy them from one branch to another, and then finally merging tested a reviewed changes to master.
This is something that git supports a thousand times better than svn or cvs or others.
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
Force pushing a fix to pretend it never happened is simply terrorism.
Hyperbole anyone?
-
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I'm not superhuman and neither are the people I work with. We all make mistakes all the time. We use a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Git makes that workflow easy and pleasant. SVN and other systems in general do not. As has been remarked by others "SVN supports branching — it doesn't support merging"
-
SVN merge (https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html)
I'll grant you that it's not as sophisticated as git merge, but it works. The only issues I have with it (and the main reason I don't often use it) is the resolve function. Battling that can be almost as dense as git sometimes.
Merging on git isn't that intuitive, either. I seem to end up merging the branch into the trunk and then the trunk back into the branch, otherwise the pretty graph remains open-ended.
-
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I don't, you just choose to see it as that because I, and others, disagree with you as to how wonderful git is, or is not, and get increasingly patronising and belittling with every reply - such as lecturing us as to the very basics of how git works.
It's quite clear that you're a git fanboy, nobody but a fanboy would have said "Git makes that workflow easy and pleasant" who had dealt with it at any scale at all. In fact the phrase "Git makes that workflow easy and pleasant" will, I'm sure, have elicited a cynical laugh out of more than one reader. There's little mileage in trying to debate the issues with a "true believer".
-
a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Can you make a practical example? This sounds very interesting.
-
Also don't forget about hiding all the errors people make and the audit trail with rebase! :-DD
-
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I don't, you just choose to see it as that because I, and others, disagree with you as to how wonderful git is, or is not, and get increasingly patronising and belittling with every reply - such as lecturing us as to the very basics of how git works.
It's quite clear that you're a git fanboy, nobody but a fanboy would have said "Git makes that workflow easy and pleasant" who had dealt with it at any scale at all. In fact the phrase "Git makes that workflow easy and pleasant" will, I'm sure, have elicited a cynical laugh out of more than one reader. There's little mileage in trying to debate the issues with a "true believer".
Good grief, you really see the world as black and white!
I doubt that I could even reliably list all the version control systems I've used for real paying work. But let's try. SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, MPW Projector, ClearCase, Perforce, Mercurial, git.
I resisted git for ages in the late 00's as Mercurial especially seemed to do everything about as well and some things better. But there is no getting around the fact that git won in mindshare and widespread support, so I eventually capitulated.
It will surprise me if I'm using git forever. Something will eventually be both better and gain critical mass. It may even exist now. Git is certainly not without its faults, and I've even mentioned some in this thread -- for example the existence of "force" options and much advice and examples on the net encouraging people to use it. Also the inability to commit empty directories is often infuriating. Support for non-diffable files (especially large ones) could be better. Support for transparently handling compressed files with diffing (i.e. unzip then, compare and diff the expanded versions, compress the differences) would be nice. Standard incorporation of tools for better reconciling long diverged branches is much needed — I couldn't live without Michael Haggerty's git-imerge.
It's an imperfect but extremely useful tool, and not nearly as bad as you make out.
-
a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Can you make a practical example? This sounds very interesting.
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
-
I resisted git for ages in the late 00's as Mercurial especially seemed to do everything about as well and some things better. But there is no getting around the fact that git won in mindshare and widespread support, so I eventually capitulated.
It will surprise me if I'm using git forever. Something will eventually be both better and gain critical mass. It may even exist now. Git is certainly not without its faults, and I've even mentioned some in this thread -- for example the existence of "force" options and much advice and examples on the net encouraging people to use it. Also the inability to commit empty directories is often infuriating. Support for non-diffable files (especially large ones) could be better. Support for transparently handling compressed files with diffing (i.e. unzip then, compare and diff the expanded versions, compress the differences) would be nice. Standard incorporation of tools for better reconciling long diverged branches is much needed — I couldn't live without Michael Haggerty's git-imerge.
It's an imperfect but extremely useful tool, and not nearly as bad as you make out.
That actually sounds reasonable. Why then previously go off the deep end and start talking about terrorism and indulging in other hyperbole? Git is fragile, it's a horror to use, it has too many confusing options, too many dangerous options (e.g. -force), too many ways to do essentially the same thing in subtly different ways and it is way too easy for the average user to get themselves in a horrible mess, horribly quickly. I have seen the later borne out in practice dozens of times in the real world and lost track of the time I've seen wasted getting a git repo back into a sane state just because somebody made a dumb mistake or by picking 'not quite the right set of options'. Just because it doesn't corrupt the repository itself doesn't make it not fragile. It was designed around a pull model, but is used almost everywhere but by the originators in push mode. Mercurial is an oasis of calm in comparison. You've pretty much admitted you use git "because everybody else does" which at school would have elicited the response from a teacher of "Would you jump off a cliff if 'everybody else did it'?". For me git is the version control system of choice when I have no choice (i.e. I've walked into a situation where it is already in use and mandated). In its favour is it's very fast and very flexible (overly flexible).