Poll

What's your favorite version control system?

git
87 (67.4%)
mercurial
5 (3.9%)
svn
20 (15.5%)
cvs
1 (0.8%)
other
16 (12.4%)

Total Members Voted: 127

Author Topic: Version Control  (Read 15953 times)

0 Members and 1 Guest are viewing this topic.

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: Version Control
« Reply #25 on: January 19, 2020, 02:47:43 pm »
Quote
"git rev-list --count" to get the number of commits on the current branch

That might be doable, thanks :)

Quote
the build system inject the build number

What is the build number is this context?
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: Version Control
« Reply #26 on: January 19, 2020, 05:00:45 pm »
Quote
"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.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Version Control
« Reply #27 on: January 19, 2020, 05:51:06 pm »
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.

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #28 on: January 19, 2020, 06:30:16 pm »
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.
« Last Edit: January 19, 2020, 06:36:30 pm by bd139 »
 
The following users thanked this post: techman-001

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: Version Control
« Reply #29 on: January 19, 2020, 06:43:06 pm »
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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #30 on: January 19, 2020, 06:44:38 pm »
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.
« Last Edit: January 19, 2020, 06:46:44 pm by bd139 »
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: Version Control
« Reply #31 on: January 19, 2020, 06:58:38 pm »
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.  :)
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #32 on: January 19, 2020, 07:03:58 pm »
Ah yes. I am a master insults in Afrikaans these days. Comes with the territory!
 

Offline tarasv

  • Newbie
  • Posts: 4
  • Country: ca
Re: Version Control
« Reply #33 on: January 19, 2020, 08:31:02 pm »
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.
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7302
  • Country: nl
  • Current job: ATEX product design
Re: Version Control
« Reply #34 on: January 19, 2020, 11:20:01 pm »
Quote
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?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4195
  • Country: us
Re: Version Control
« Reply #35 on: January 20, 2020, 05:22:25 am »
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...

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Version Control
« Reply #36 on: January 20, 2020, 06:22:44 am »
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.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #37 on: January 20, 2020, 07:15:02 am »
Rdiff-backup does binary file diffs....
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Version Control
« Reply #38 on: January 20, 2020, 07:40:12 am »
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...
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #39 on: January 20, 2020, 07:49:25 am »
And? Storage is cheap!
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Version Control
« Reply #40 on: January 20, 2020, 08:49:03 am »
If Git is good enough for the Linux kernel source, it's definitely good enough for my purposes...
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Version Control
« Reply #41 on: January 20, 2020, 11:07:37 am »
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.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #42 on: January 20, 2020, 11:36:34 am »
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.

 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Version Control
« Reply #43 on: January 20, 2020, 11:47:06 am »
Yes, but the picture is wrong. (and was aimed at nvidia)
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
Looks like they changed their minds though, they are on Apache 2.0 now.
« Last Edit: January 20, 2020, 11:48:50 am by Jeroen3 »
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Version Control
« Reply #44 on: January 20, 2020, 11:50:22 am »
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
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: Version Control
« Reply #45 on: January 20, 2020, 12:53:47 pm »
Quote
Maybe I'm thick,

Grrrr. Turns out I am :(
« Last Edit: January 20, 2020, 01:15:26 pm by dunkemhigh »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Version Control
« Reply #46 on: January 20, 2020, 03:44:58 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Version Control
« Reply #47 on: January 20, 2020, 04:00:58 pm »
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/
 
The following users thanked this post: Siwastaja

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: Version Control
« Reply #48 on: January 20, 2020, 04:18:48 pm »
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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Version Control
« Reply #49 on: January 20, 2020, 04:25:19 pm »
Tech Talk: Linus Torvalds on Git:

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf