Poll

What's your favorite version control system?

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

Total Members Voted: 128

Author Topic: Version Control  (Read 5043 times)

0 Members and 1 Guest are viewing this topic.

Offline Karel

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

 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1529
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: Version Control
« Reply #51 on: January 20, 2020, 05:48:22 pm »
Anyway, version control systems really aren't about versioning the outputs (e.g. binaries) from a project, they're about versioning the inputs. If people complain about version control systems that behave badly because someone chose poor inputs that have to be stored in binary forms that are highly labile with small changes then surely the finger needs pointing at the latter not the version control system.

That is my point exactly.

git handles binary file formats where a small change by the user results in a small number of bytes changed in the file just fine.
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #52 on: January 20, 2020, 05:57:03 pm »
The crows of people who haven't tried dealing with and merging a 400Mb JSON or XML file :-DD

"but it's a text format"

Hmm... give me it in a zip thanks.

 

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #53 on: January 20, 2020, 11:21:18 pm »

Single user: learn and use Fossil.
Small team: One subversion repo for all projects. Lightweight branches.
Large team: lots of subversion repositories. Software composition via repo links. Light branches per repository.
really skilled team (rare): learn and use fossil.


Now there is a breath of fresh air!

I'd be a millionaire Fossil user if I had a dollar for every time I've read the following:

"I use GIT because  :-* :-* :-* GITHUB :-* :-* :-*"
or
"I use GIT because if it's good enough for the Linux kernel, then it's good enough for my Arduino * project"

* Today's trivia, there are 56 "arduino cat feeder" projects on Github and zero on Sourceforge.
 
The following users thanked this post: Siwastaja, bd139

Offline olkipukki

  • Frequent Contributor
  • **
  • Posts: 447
  • Country: 00
Re: Version Control
« Reply #54 on: January 20, 2020, 11:40:54 pm »
.... Just to get an idea of the "popularity" of different VCS, ...

Sorry, I didn't vote since the question mentioned 'What's your favorite version control system?' Unfortunately, I don't have one.

I stopped use svn while ago, basically once a laptop become as one of primary tools.
git is okay for most of stuff these days, except some c******f**k happened with git-lfs...  :palm:

fossil looks very promising and I like idea all-in-one. :-+

still on a mission to find out how to manage binary assets  :-//

 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #55 on: January 20, 2020, 11:57:02 pm »
I stick large binaries in amazon S3. You can enable bucket versioning.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #56 on: January 21, 2020, 12:03:58 am »
Sounds terrible! I still have nightmares about Word documents with links to diagrams instead of embedded stuff, then finding out at the worst possible moment the linked-to folder no longer exists. Or some git (ho ho) sent me a document with links to their local filesystem. Always embedded everything since then :)
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1561
  • Country: 00
Re: Version Control
« Reply #57 on: January 21, 2020, 07:26:03 am »
Sounds terrible! I still have nightmares about Word documents with links to diagrams instead of embedded stuff, then finding out at the worst possible moment the linked-to folder no longer exists. Or some git (ho ho) sent me a document with links to their local filesystem. Always embedded everything since then :)

I know, it's called "Portable Document Format". It's the only format that makes sure it looks the same everywhere. For sure no office shit.
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #58 on: January 21, 2020, 07:58:52 am »
Yep. LaTeX in PDF out.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1561
  • Country: 00
Re: Version Control
« Reply #59 on: January 21, 2020, 08:38:33 am »
Single user: learn and use Git
Small team: Git.
Large team: Git.
really skilled team (rare): learn and use Git.

 >:D
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #60 on: January 21, 2020, 09:03:35 am »
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.
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 2156
  • Country: pl
Re: Version Control
« Reply #61 on: January 21, 2020, 09:04:45 am »
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?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1561
  • Country: 00
Re: Version Control
« Reply #62 on: January 21, 2020, 09:23:21 am »
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.

I don't know about those "charlatans" you are talking about.
I believe Linus when he says it outperforms all alternatives, wether it is price, speed, flexibility or integrity.
If I have to choose to believe you or Linus, I choose Linus
(no offence, I have high regards of you and most of the time I appreciate/agree what you are writing here).
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #63 on: January 21, 2020, 09:35:58 am »
Yeah. No private branching? No rebase?

Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?

fossil commit --private ?

Such a broken process. Bisect uses a binary search so you need a source of truth that says "yes that build did X" so the scope of effort is minimally T*O(log N) where N is commit span and T is the average build time. That can't be improved upon. But bisect is last resort in the middle of a shitty process. If you have to use bisect you fucked up somewhere already. I mean for example the RTT build time to integrate the current product I'm working on is around 4 hours. Do you have time to bisect that when there's a regression? Nope! You better have some skills and some history available.

But nope, you squashed it and that erases whodunnit and whendunnit in the process and only tells you who merged it to master. That's fine until you get malicious user or a nasty compliance question to answer. You're purposely erasing history.

I expand my comment to "people don't know how to manage software properly".

Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.

I don't know about those "charlatans" you are talking about.
I believe Linus when he says it outperforms all alternatives, wether it is price, speed, flexibility or integrity.
If I have to choose to believe you or Linus, I choose Linus
(no offence, I have high regards of you and most of the time I appreciate/agree what you are writing here).

They are charlatans. "a person falsely claiming to have a special knowledge or skill.". I've watched several "git experts" hit a wall pretty hard and that is almost always when everyone is wading up to their knees in shit at the time.

Linus sits in a monoculture. He's a kernel developer. He's a technical expert. He has a tightly controlled team. It works for him. It works for the Linux kernel. On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are! So all is not good in the house of git. It's a mess of hypocrisy at best. A cargo cult. At the core it works for the use case it was designed for but have you tried sending patches by email to upstreams users in git? Oooh that's a world of hell.

On top of that despite the massive ego, he really doesn't speak for the vast and disparate set of teams out there which range from graphic designers who want to just frig some CSS in a project to people up to their eyes in threading bugs inside event reactors in trading systems, delivering large enterprise software behemoths with a thousand dependencies. What matters there is the process, the controls, the methodology and the outcome. What we tend not to want is tools with a thousand foot guns built in that can span a reasonable set of use cases.

Git has a high cost in these environments and those environments are far far far far more common than the world that Linus speaks of.

https://ohshitgit.com/ is a fine example of the disparity between the user and the knowledge required to run git.

Edit: Incidentally I'm paid to shut up and use it. But not my funeral!
« Last Edit: January 21, 2020, 09:45:21 am by bd139 »
 

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #64 on: January 21, 2020, 09:54:36 am »
Yeah. No private branching? No rebase?

Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?

A rebase is just a merge that forgets where it came from ...

https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md

https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

 
The following users thanked this post: bd139

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1561
  • Country: 00
Re: Version Control
« Reply #65 on: January 21, 2020, 10:03:14 am »
On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are!

I was talking about Git, not github (which I left almost the same day microsoft bought it).
I think we agree about Git != github.
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 2156
  • Country: pl
Re: Version Control
« Reply #66 on: January 21, 2020, 11:05:03 am »
Bisect is standard process in projects which take a few minutes tops to incrementally recompile, and there is many such projects. If the project maintains a "no untested commits on master" policy (and anyone serious does), bisect is quick and can easily be done by any intern, monkey, sometimes even the customer, and it neatly nails the regression down to a single commit.

In a properly managed git repository the commits aren't "merge XYZ and forget where it came from". You split them into logical series after the complete implementation has been worked out, along the lines of:
1. prepare X to accept new Y
2. update Y
3. expand Z to use new X and Y functionality

It seems that with fossil, I would be forced to bisect between meaningless mammoth merge commits and then descend into a hairy development branch which truthfully reflect the development process, i.e. bugs, non-building revisions, dead ends, reverts...

There is nothing preventing you from having a policy to preserve those branches in git, although in practice few do. I tend to keep them on my own machine even if the employer doesn't care.

If you use gerrit, all the development history is kept by gerrit, complete with code review, discussion, everything. But you don't need to look into that garbage if you are just viewing the changelog or bisecting.


Don't post me links to fossil website. I just came back from there and that's why I rant :-DD
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1529
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: Version Control
« Reply #67 on: January 21, 2020, 01:16:13 pm »
Bisect is standard process in projects which take a few minutes tops to incrementally recompile

That doesn't make sense.

The longer the project takes to build, the *more* valuable bisect is relative to backing up one commit at a time to find the problem.
 
The following users thanked this post: Tepe, bd139

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 650
  • Country: au
  • Electronics technician for the last 47 years
Re: Version Control
« Reply #68 on: January 21, 2020, 02:02:37 pm »
Bisect is standard process in projects which take a few minutes tops to incrementally recompile, and there is many such projects. If the project maintains a "no untested commits on master" policy (and anyone serious does), bisect is quick and can easily be done by any intern, monkey, sometimes even the customer, and it neatly nails the regression down to a single commit.

In a properly managed git repository the commits aren't "merge XYZ and forget where it came from". You split them into logical series after the complete implementation has been worked out, along the lines of:
1. prepare X to accept new Y
2. update Y
3. expand Z to use new X and Y functionality

It seems that with fossil, I would be forced to bisect between meaningless mammoth merge commits and then descend into a hairy development branch which truthfully reflect the development process, i.e. bugs, non-building revisions, dead ends, reverts...

There is nothing preventing you from having a policy to preserve those branches in git, although in practice few do. I tend to keep them on my own machine even if the employer doesn't care.

If you use gerrit, all the development history is kept by gerrit, complete with code review, discussion, everything. But you don't need to look into that garbage if you are just viewing the changelog or bisecting.

Don't post me links to fossil website. I just came back from there and that's why I rant :-DD

Now I'm confused .....
 Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT, or are you ranting because your emotive laden anti Fossil diatribe "meaningless mammoth merge ... hairy development branch ... " (whilst impressively demonstrating initiative and flair for fud creation), really isn't doing anything to make Fossil appear lacking compared to GIT ?

I know !!!

It's because the Fossil inbuilt help only takes 61 lines to explain the use of BISECT, compared to the 434 lines it takes GIT ? :-DD


GIT ... what SCM task would you like to obfuscate today ?
 
The following users thanked this post: bd139

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5344
  • Country: fr
Re: Version Control
« Reply #69 on: January 21, 2020, 02:24:29 pm »
On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are!

I was talking about Git, not github (which I left almost the same day microsoft bought it).
I think we agree about Git != github.

I think bd139 is still making a very good point. A large number of git users (whether they are using github or another platform) are in fact using git more as a centralized system than anything else, which is not what git was meant to be about, and which means that many just use git because it's popular, not because of its intrinsic qualities.

I'll make some kind of summary/comment of the results and what has been discussed here when we reach ~100 votes.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 1915
Re: Version Control
« Reply #70 on: January 21, 2020, 02:45:58 pm »
A big plus for git (and svn) over the likes of fossil is Tortoisegit/svn/hg on Windows. Worth every penny.
 
The following users thanked this post: Bassman59

Offline magic

  • Super Contributor
  • ***
  • Posts: 2156
  • Country: pl
Re: Version Control
« Reply #71 on: January 21, 2020, 03:05:44 pm »
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
That doesn't make sense.
I was responding to the case when build takes so long that you would rather comb through changelogs than spend a week bisecting.

Now I'm confused .....
 Are you ranting because you have just discovered that Fossil has everything GIT has, or are you ranting because you have found that Fossil is different to GIT
I think it's the latter. I'm literally shaking and triggered by their insistence on preserving accurate history over creating a fake one which is convenient to review and debug ;D
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1529
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: Version Control
« Reply #72 on: January 21, 2020, 04:58:30 pm »
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
That doesn't make sense.
I was responding to the case when build takes so long that you would rather comb through changelogs than spend a week bisecting.

bd139 quoted a 4 hour build time as not being worth bisecting.

A week of bisecting with a 4 hour build time lets you find the one bad commit in the last 2^42 = 4,398,046,511,104 commits.

That's a lot of changelogs to comb through.
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15021
  • Country: gb
Re: Version Control
« Reply #73 on: January 21, 2020, 05:09:13 pm »
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.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1529
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: Version Control
« Reply #74 on: January 21, 2020, 05:27:06 pm »
It's far far easier to write a test case, see what explodes then use the repo blame function rather than sit and wait a week on a 4 hour build.

And of course that's what you do for 90% or 95% of bugs.

But there's the other 5%...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf