Version Control - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2020, 03:22:45 pm
content: This poll is not meant to trigger flame wars, so please refrain. 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.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2020, 03:58:19 pm
content: Quote from: blueskull on January 18, 2020, 03:44:26 pmWhy 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 18, 2020, 04:24:12 pm
content: SVN is onmaintenance, only bugfixes and minor performance tweaks.Mercurial isdying.CVS,is that still around?.We've made it into a git monopoly...

author: RoGeorge
author_rank: Super Contributor
timestamp: January 18, 2020, 04:57:19 pm
content: My favorite is "Save as".

author: PlainName
author_rank: Super Contributor
timestamp: January 18, 2020, 05:16:37 pm
content: QuoteI 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.)

author: brucehoult
author_rank: Super Contributor
timestamp: January 18, 2020, 06:58:48 pm
content: 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.

author: PlainName
author_rank: Super Contributor
timestamp: January 18, 2020, 08:25:57 pm
content: 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

author: brucehoult
author_rank: Super Contributor
timestamp: January 18, 2020, 09:43:46 pm
content: Quote from: dunkemhigh on January 18, 2020, 08:25:57 pmNo, 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.QuoteNo, 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.QuoteIn 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.

author: magic
author_rank: Super Contributor
timestamp: January 18, 2020, 09:56:36 pm
content: Unless you --force something or remove the .git directory or delete files that have never been committed, your data most likely still exist.

author: sleemanj
author_rank: Super Contributor
timestamp: January 18, 2020, 10:31:44 pm
content: 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.

author: nardev
author_rank: Unknown
timestamp: January 18, 2020, 11:48:36 pm
content: 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.

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 12:48:27 am
content: QuoteOnly 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 commitmustgo 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?

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 12:51:16 am
content: QuoteYes, no question. One doesn't have to follow the herd, though - horses for coursesIt becomes a bit of an issue when ones tools become obsolete because they are no longer popular.

author: Veteran68
author_rank: Frequent Contributor
timestamp: January 19, 2020, 01:38:26 am
content: I'm a git convert.Quote from: Jeroen3 on January 18, 2020, 04:24:12 pmNot 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 19, 2020, 02:53:40 am
content: 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 afindorgrepcommand 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-hor--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.

author: andersm
author_rank: Super Contributor
timestamp: January 19, 2020, 07:29:22 am
content: Quote from: nardev on January 18, 2020, 11:48:36 pmOverall, 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.

author: magic
author_rank: Super Contributor
timestamp: January 19, 2020, 08:27:05 am
content: Quote from: dunkemhigh on January 19, 2020, 12:48:27 amYou certainly need at least one repo which never gets deletedI 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

author: tszaboo
author_rank: Super Contributor
timestamp: January 19, 2020, 08:47:02 am
content: Quote from: dunkemhigh on January 19, 2020, 12:48:27 amOne 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.

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 11:41:09 am
content: Quoteoh, 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.)

author: brucehoult
author_rank: Super Contributor
timestamp: January 19, 2020, 11:58:30 am
content: Quote from: NANDBlog on January 19, 2020, 08:47:02 amThat'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.

author: bd139
author_rank: Super Contributor
timestamp: January 19, 2020, 12:03:06 pm
content: I use Fossil for personal projects:https://fossil-scm.org/home/doc/trunk/www/index.wikiIt'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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 19, 2020, 12:09:28 pm
content: Quote from: dunkemhigh on January 19, 2020, 11:41:09 amVersion 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 ashttps://semver.org/

author: Cerebus
author_rank: Super Contributor
timestamp: January 19, 2020, 12:22:31 pm
content: Voted 'other' because: myfavouriteVCS of those listed would be mercurial but a need to collaborate with lesser morals means that git is themost usedfor me.Edited to add: I too have been contemplating switching to fossil for personal work.

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 12:39:07 pm
content: QuoteMy choice of words wasn't greatI 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.

author: andersm
author_rank: Super Contributor
timestamp: January 19, 2020, 02:37:14 pm
content: Quote from: dunkemhigh on January 19, 2020, 12:39:07 pmYou 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.

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 02:47:43 pm
content: QuoteThat might be doable, thanksQuoteWhat is the build number is this context?

author: PlainName
author_rank: Super Contributor
timestamp: January 19, 2020, 05:00:45 pm
content: Quote from: dunkemhigh on January 19, 2020, 02:47:43 pmAh, 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.

author: andersm
author_rank: Super Contributor
timestamp: January 19, 2020, 05:51:06 pm
content: Quote from: dunkemhigh on January 19, 2020, 05:00:45 pmExactly. 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.

author: bd139
author_rank: Super Contributor
timestamp: January 19, 2020, 06:30:16 pm
content: 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.

author: Cerebus
author_rank: Super Contributor
timestamp: January 19, 2020, 06:43:06 pm
content: Quote from: bd139 on January 19, 2020, 06:30:16 pmI 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.

author: bd139
author_rank: Super Contributor
timestamp: January 19, 2020, 06:44:38 pm
content: You may have worked with meEdit: 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.

author: Cerebus
author_rank: Super Contributor
timestamp: January 19, 2020, 06:58:38 pm
content: Quote from: bd139 on January 19, 2020, 06:44:38 pmI 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 particularbête noireI had in mind at the time.

author: bd139
author_rank: Super Contributor
timestamp: January 19, 2020, 07:03:58 pm
content: Ah yes. I am a master insults in Afrikaans these days. Comes with the territory!

author: tarasv
author_rank: Newbie
timestamp: January 19, 2020, 08:31:02 pm
content: Quote from: Jeroen3 on January 19, 2020, 12:09:28 pmVersioning 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.

author: tszaboo
author_rank: Super Contributor
timestamp: January 19, 2020, 11:20:01 pm
content: Quote from: dunkemhigh on January 19, 2020, 11:41:09 amSVN, you commit something, number increases. Your coworker commits something, number increases. It doesnt have to be more complicated than that.Quote from: brucehoult on January 19, 2020, 11:58:30 amSo 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?

author: westfw
author_rank: Super Contributor
timestamp: January 20, 2020, 05:22:25 am
content: 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...

author: brucehoult
author_rank: Super Contributor
timestamp: January 20, 2020, 06:22:44 am
content: Quote from: NANDBlog on January 19, 2020, 11:20:01 pmAnd 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.

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 07:15:02 am
content: Rdiff-backup does binary file diffs....

author: brucehoult
author_rank: Super Contributor
timestamp: January 20, 2020, 07:40:12 am
content: Quote from: bd139 on January 20, 2020, 07:15:02 amYes, 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...

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 07:49:25 am
content: And? Storage is cheap!

author: Karel
author_rank: Super Contributor
timestamp: January 20, 2020, 08:49:03 am
content: If Git is good enough for the Linux kernel source, it's definitely good enough for my purposes...

author: Jeroen3
author_rank: Super Contributor
timestamp: January 20, 2020, 11:07:37 am
content: 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.

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 11:36:34 am
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 20, 2020, 11:47:06 am
content: Yes, but the picture is wrong.(and was aimed at nvidia)https://en.wikipedia.org/wiki/BitKeeper#Pricing_changehttps://web.archive.org/web/20070929115009/http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481Looks like they changed their minds though, they are on Apache 2.0 now.

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 11:50:22 am
content: 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=2Bitkeeper is dead.I love Linux flamewars!

author: PlainName
author_rank: Super Contributor
timestamp: January 20, 2020, 12:53:47 pm
content: QuoteGrrrr. Turns out I am

author: brucehoult
author_rank: Super Contributor
timestamp: January 20, 2020, 03:44:58 pm
content: Quote from: bd139 on January 20, 2020, 07:49:25 amStorage 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 20, 2020, 04:00:58 pm
content: Quote from: bd139 on January 20, 2020, 11:36:34 amI 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 examplehttps://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/

author: Cerebus
author_rank: Super Contributor
timestamp: January 20, 2020, 04:18:48 pm
content: Quote from: brucehoult on January 20, 2020, 03:44:58 pmStorageisthat 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 theoutputs(e.g. binaries) from a project, they're about versioning theinputs. 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.

author: Karel
author_rank: Super Contributor
timestamp: January 20, 2020, 04:25:19 pm
content: Tech Talk: Linus Torvalds on Git:

author: brucehoult
author_rank: Super Contributor
timestamp: January 20, 2020, 05:48:22 pm
content: Quote from: Cerebus on January 20, 2020, 04:18:48 pmThat 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.

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 05:57:03 pm
content: The crows of people who haven't tried dealing with and merging a 400Mb JSON or XML file"but it's a text format"Hmm... give me it in a zip thanks.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 20, 2020, 11:21:18 pm
content: Quote from: bd139 on January 19, 2020, 06:30:16 pmNow 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 becauseGITHUB"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.

author: olkipukki
author_rank: Frequent Contributor
timestamp: January 20, 2020, 11:40:54 pm
content: Quote from: SiliconWizard on January 18, 2020, 03:22:45 pmSorry, I didn't vote since the question mentioned 'What's yourfavoriteversion 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...fossil looks very promising and I like idea all-in-one.still on a mission to find out how to manage binary assets

author: bd139
author_rank: Super Contributor
timestamp: January 20, 2020, 11:57:02 pm
content: I stick large binaries in amazon S3. You can enable bucket versioning.

author: PlainName
author_rank: Super Contributor
timestamp: January 21, 2020, 12:03:58 am
content: 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 totheirlocal filesystem. Always embedded everything since then

author: Karel
author_rank: Super Contributor
timestamp: January 21, 2020, 07:26:03 am
content: Quote from: dunkemhigh on January 21, 2020, 12:03:58 amI 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.

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 07:58:52 am
content: Yep. LaTeX in PDF out.

author: Karel
author_rank: Super Contributor
timestamp: January 21, 2020, 08:38:33 am
content: Single user: learn and use GitSmall team: Git.Large team: Git.really skilled team (rare): learn and use Git.

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 09:03:35 am
content: 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.

author: magic
author_rank: Super Contributor
timestamp: January 21, 2020, 09:04:45 am
content: 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?

author: Karel
author_rank: Super Contributor
timestamp: January 21, 2020, 09:23:21 am
content: Quote from: bd139 on January 21, 2020, 09:03:35 amI 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).

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 09:35:58 am
content: Quote from: magic on January 21, 2020, 09:04:45 amfossil 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".Quote from: Karel on January 21, 2020, 09:23:21 amThey 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!

author: techman-001
author_rank: Frequent Contributor
timestamp: January 21, 2020, 09:54:36 am
content: Quote from: magic on January 21, 2020, 09:04:45 amA rebase is just a merge that forgets where it came from ...https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.mdhttps://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

author: Karel
author_rank: Super Contributor
timestamp: January 21, 2020, 10:03:14 am
content: Quote from: bd139 on January 21, 2020, 09:35:58 amI was talking about Git, not github (which I left almost the same day microsoft bought it).I think we agree about Git != github.

author: magic
author_rank: Super Contributor
timestamp: January 21, 2020, 11:05:03 am
content: 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 Y2. update Y3. expand Z to use new X and Y functionalityIt 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

author: brucehoult
author_rank: Super Contributor
timestamp: January 21, 2020, 01:16:13 pm
content: Quote from: magic on January 21, 2020, 11:05:03 amThat 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 21, 2020, 02:02:37 pm
content: Quote from: magic on January 21, 2020, 11:05:03 amNow 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 ?GIT ... what SCM task would you like to obfuscate today ?

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 21, 2020, 02:24:29 pm
content: Quote from: Karel on January 21, 2020, 10:03:14 amI 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.

author: PlainName
author_rank: Super Contributor
timestamp: January 21, 2020, 02:45:58 pm
content: A big plus for git (and svn) over the likes of fossil is Tortoisegit/svn/hg on Windows. Worth every penny.

author: magic
author_rank: Super Contributor
timestamp: January 21, 2020, 03:05:44 pm
content: Quote from: brucehoult on January 21, 2020, 01:16:13 pmI was responding to the case when build takes so long that you would rather comb through changelogs than spend a week bisecting.Quote from: techman-001 on January 21, 2020, 02:02:37 pmI 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

author: brucehoult
author_rank: Super Contributor
timestamp: January 21, 2020, 04:58:30 pm
content: Quote from: magic on January 21, 2020, 03:05:44 pmbd139 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.

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 05:09:13 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 21, 2020, 05:27:06 pm
content: Quote from: bd139 on January 21, 2020, 05:09:13 pmAnd of course that's what you do for 90% or 95% of bugs.But there's the other 5%...

author: techman-001
author_rank: Frequent Contributor
timestamp: January 21, 2020, 07:55:11 pm
content: Quote from: magic on January 21, 2020, 03:05:44 pmI sympathize completely and I'd send you a nice cuddly stuffed Fossil mascot to hug in your safe space if I couldI 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

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 08:04:16 pm
content: You might want to use svn for that

author: techman-001
author_rank: Frequent Contributor
timestamp: January 21, 2020, 08:07:08 pm
content: Quote from: SiliconWizard on January 21, 2020, 02:24:29 pmThat could be a while, or never because it's looking like only 60 - 70 posters among the hundreds of thousands on this forum actuallyusea SCM.To most Github users, I suspect GIT is just a downloader.

author: bsudbrink
author_rank: Frequent Contributor
timestamp: January 21, 2020, 08:11:26 pm
content: Perforce

author: magic
author_rank: Super Contributor
timestamp: January 21, 2020, 10:42:42 pm
content: 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

author: PlainName
author_rank: Super Contributor
timestamp: January 21, 2020, 11:01:36 pm
content: 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 beactuallyremoved, just hidden.

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 11:27:02 pm
content: Quote from: magic on January 21, 2020, 10:42:42 pmCode 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...

author: olkipukki
author_rank: Frequent Contributor
timestamp: January 21, 2020, 11:29:44 pm
content: Quote from: bd139 on January 20, 2020, 07:49:25 amReally? 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"?

author: bd139
author_rank: Super Contributor
timestamp: January 21, 2020, 11:36:17 pm
content: Quote from: olkipukki on January 21, 2020, 11:29:44 pmAka Thursday for me. It’s not about saving money but shifting capex to opex. No one has worked that out yet.

author: olkipukki
author_rank: Frequent Contributor
timestamp: January 21, 2020, 11:36:50 pm
content: Quote from: bd139 on January 20, 2020, 11:57:02 pmHow 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 22, 2020, 02:34:02 am
content: Quote from: magic on January 21, 2020, 10:42:42 pmFanboys ?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

author: bd139
author_rank: Super Contributor
timestamp: January 22, 2020, 07:58:44 am
content: Quote from: olkipukki on January 21, 2020, 11:36:50 pmDependencies ~400Mb a go. VM images 8-20Gb a go. Link varies. I’m happy on 76mbits down

author: sleemanj
author_rank: Super Contributor
timestamp: January 22, 2020, 08:28:29 am
content: Quote from: techman-001 on January 22, 2020, 02:34:02 amTIL that Tcl/Tk still exists!Seriously I thought that would be deader than CVS at this point!

author: PlainName
author_rank: Super Contributor
timestamp: January 23, 2020, 12:01:00 am
content: Quote from: bd139 on January 20, 2020, 11:57:02 pmDoesn'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.

author: guenthert
author_rank: Frequent Contributor
timestamp: January 23, 2020, 01:14:39 am
content: Quote from: bd139 on January 20, 2020, 11:50:22 amShowing Nvidia, who treated Linux as second-class citizen, the finger got him then lot of sympathy. And it seemed to have helped.Quote from: bd139 on January 20, 2020, 11:50:22 amNot 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.Quote from: bd139 on January 20, 2020, 11:50:22 amSo much that you attempt to start one with half-truth and out-of-context quotations?

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2020, 08:34:50 am
content: 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.Quote from: dunkemhigh on January 23, 2020, 12:01:00 amDepends on your workflow. If you have to version large binaries (Gb in size) I haven’t found a better option.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 23, 2020, 11:40:20 am
content: 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.

author: bd139
author_rank: Super Contributor
timestamp: January 23, 2020, 11:55:50 am
content: Seen that. That's plainly aimed at upper management not end users

author: Jan Audio
author_rank: Frequent Contributor
timestamp: January 25, 2020, 05:25:29 pm
content: So i searched what GIT is and found out it is a software-application where in you save your source codes ?ha ha ha

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 04, 2020, 07:01:00 am
content: Quote from: Jan Audio on January 25, 2020, 05:25:29 pmThat's a joke right...?

author: frogg
author_rank: Regular Contributor
timestamp: February 12, 2020, 09:16:06 pm
content: I'm personally a fan of git, but for developers using windows, I think subversion is attractive.

author: PlainName
author_rank: Super Contributor
timestamp: February 12, 2020, 09:24:39 pm
content: I am intrigued! Why would Windows make subversion more attractive than git?

author: bd139
author_rank: Super Contributor
timestamp: February 12, 2020, 09:30:53 pm
content: TortoiseSVN. UI that isn't shit and mortals can operate.I slightly hoped this thread had died. Oh well.

author: PlainName
author_rank: Super Contributor
timestamp: February 12, 2020, 09:47:24 pm
content: But there is Tortoisegit, and TortoiseHg.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: February 12, 2020, 09:52:22 pm
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 13, 2020, 02:27:32 am
content: Quote from: bd139 on February 12, 2020, 09:30:53 pmWell, the voting part is definitely, but hearing from others their preferred workflow is definitely interesting.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2020, 07:16:12 pm
content: Quote from: Nominal Animal on February 13, 2020, 02:27:32 amIt'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.

author: PlainName
author_rank: Super Contributor
timestamp: February 13, 2020, 07:27:07 pm
content: QuoteSame 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2020, 07:46:48 pm
content: Quote from: dunkemhigh on February 13, 2020, 07:27:07 pmI 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.Quote from: dunkemhigh on February 13, 2020, 07:27:07 pmUsing 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.

author: PlainName
author_rank: Super Contributor
timestamp: February 13, 2020, 08:21:31 pm
content: I mean to say 'unadventurously'Speling cheker got to it

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 14, 2020, 12:58:22 am
content: Quote from: SiliconWizard on February 13, 2020, 07:16:12 pmI'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 ofsudo 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; evenfind ... -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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2020, 03:02:12 pm
content: Quote from: Nominal Animal on February 14, 2020, 12:58:22 amWell, 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.

author: bd139
author_rank: Super Contributor
timestamp: February 15, 2020, 03:47:39 pm
content: 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.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: February 19, 2020, 01:59:54 pm
content: 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.

author: mrflibble
author_rank: Super Contributor
timestamp: February 27, 2020, 07:13:05 pm
content: There we go. One vote closer to that 100 target. And yes, +1 for git.Have used cvs in the past, svn after that, and git after that. Have used mercurial in the past as well, and would not mind it for new projects. I most certainly wouldnotuse cvs again in any new project. Subversion, mmmmh, maybe, provided the project will not have more that a fewfeaturebranches 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).

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2020, 06:33:07 pm
content: 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:QuoteMercurial 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.

author: PlainName
author_rank: Super Contributor
timestamp: March 27, 2020, 07:02:05 pm
content: QuoteAlternatively, 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.

author: PlainName
author_rank: Super Contributor
timestamp: April 13, 2020, 06:21:45 pm
content: Christ, IHATEgit.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.

author: Bassman59
author_rank: Super Contributor
timestamp: April 13, 2020, 08:11:54 pm
content: Quote from: dunkemhigh on April 13, 2020, 06:21:45 pmThe 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!"

author: bd139
author_rank: Super Contributor
timestamp: April 13, 2020, 08:12:45 pm
content: I just send thehttps://ohshitgit.comand job done

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 14, 2020, 01:04:14 am
content: Do not hesitate to take a look at Mercurial if you have a problem with git. Seriously.

author: PlainName
author_rank: Super Contributor
timestamp: April 14, 2020, 06:36:45 am
content: 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.

author: 0db
author_rank: Frequent Contributor
timestamp: April 14, 2020, 08:06:14 am
content: Quote from: dunkemhigh on April 14, 2020, 06:36:45 amI have been using git for personal projects since 2009. I haven't yet found any problem and I never felt frustrated with it.

author: bd139
author_rank: Super Contributor
timestamp: April 14, 2020, 08:29:34 am
content: 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 etcIf 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

author: brucehoult
author_rank: Super Contributor
timestamp: April 14, 2020, 08:51:39 am
content: That's not going to work, because one of git's few actual design faults is you can't add an empty directory

author: bd139
author_rank: Super Contributor
timestamp: April 14, 2020, 08:53:15 am
content: Still drinking my first coffee of the day.Add a file to each dirAlso, works in SVN

author: PlainName
author_rank: Super Contributor
timestamp: April 14, 2020, 09:24:52 am
content: QuoteHow 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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 14, 2020, 01:35:21 pm
content: This isnothelped 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 gitsubmodulesandman git-submoduleand then try:git submodule statusand, if you're lucky and they have done things "by the book":git submodule updatewill get you to where you want to be.

author: bd139
author_rank: Super Contributor
timestamp: April 14, 2020, 01:40:13 pm
content: I've spent the last two weeks thinking that perhaps I should write something better than git. And register whateverhub.com

author: PlainName
author_rank: Super Contributor
timestamp: April 14, 2020, 02:10:01 pm
content: Thanks for the advice, but...QuoteThat 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

author: Cerebus
author_rank: Super Contributor
timestamp: April 14, 2020, 04:45:19 pm
content: Quote from: dunkemhigh on April 14, 2020, 02:10:01 pmMust 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 14, 2020, 05:00:48 pm
content: Quote from: dunkemhigh on April 14, 2020, 06:36:45 amYou can use git for accessing code that's on git, and use something else for your own projects.Quote from: dunkemhigh on April 14, 2020, 06:36:45 amNever had a problem with that.Quote from: dunkemhigh on April 14, 2020, 06:36:45 amDitto.Quote from: dunkemhigh on April 14, 2020, 06:36:45 amI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 12:50:46 am
content: Quote from: dunkemhigh on April 14, 2020, 02:10:01 pmHaving 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 likehttps://github.com/riscv/riscv-gnu-toolchainwhich 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/

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 01:05:39 am
content: Quote from: Cerebus on April 14, 2020, 04:45:19 pmI 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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 15, 2020, 01:33:38 am
content: Quote from: brucehoult on April 15, 2020, 01:05:39 amNo, 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 onlystrictlytrue. As you point out git will happily trash your universe if you ask it to, and it makes itsoeasy 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 03:41:27 am
content: Quote from: Cerebus on April 15, 2020, 01:33:38 amIf 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.QuoteMy point, which I stand by, is that a series of easy to remember and understand commands is sufficient.QuoteStop 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.

author: bd139
author_rank: Super Contributor
timestamp: April 15, 2020, 08:17:47 am
content: Quote from: brucehoult on April 15, 2020, 03:41:27 amThat'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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 15, 2020, 01:27:08 pm
content: Quote from: brucehoult on April 15, 2020, 03:41:27 amYou 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 driveproperly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.QuoteHyperbole anyone?

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 09:20:10 pm
content: Quote from: Cerebus on April 15, 2020, 01:27:08 pmI'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"

author: PlainName
author_rank: Super Contributor
timestamp: April 15, 2020, 09:36:43 pm
content: SVN mergeI'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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 15, 2020, 09:44:21 pm
content: Quote from: brucehoult on April 15, 2020, 09:20:10 pmI 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".

author: 0db
author_rank: Frequent Contributor
timestamp: April 15, 2020, 09:46:09 pm
content: Quote from: brucehoult on April 15, 2020, 09:20:10 pmCan you make a practical example? This sounds very interesting.

author: bd139
author_rank: Super Contributor
timestamp: April 15, 2020, 10:07:01 pm
content: Also don't forget about hiding all the errors people make and the audit trail with rebase!

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 11:02:17 pm
content: Quote from: Cerebus on April 15, 2020, 09:44:21 pmGood 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2020, 11:04:42 pm
content: Quote from: 0db on April 15, 2020, 09:46:09 pmhttps://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

author: Cerebus
author_rank: Super Contributor
timestamp: April 16, 2020, 10:26:28 am
content: Quote from: brucehoult on April 15, 2020, 11:02:17 pmThat actually sounds reasonable. Why then previously go off the deep end and start talking about terrorism and indulging in other hyperbole? Gitisfragile, 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'sveryfast and very flexible (overly flexible).