Version Control

[brucehoult]

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.

[bd139]

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.

[techman-001]

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.

[olkipukki]

.... 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... 

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

still on a mission to find out how to manage binary assets 

[bd139]

I stick large binaries in amazon S3. You can enable bucket versioning.

[PlainName]

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

[Karel]

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.

[bd139]

Yep. LaTeX in PDF out.

[Karel]

Single user: learn and use Git
Small team: Git.
Large team: Git.
really skilled team (rare): learn and use Git.

 

[bd139]

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.

[magic]

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?

[Karel]

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).

[bd139]

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!

[techman-001]

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

[Karel]

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.

[magic]

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

[brucehoult]

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.

[techman-001]

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

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 ?


GIT ... what SCM task would you like to obfuscate today ?

[SiliconWizard]

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.

[PlainName]

A big plus for git (and svn) over the likes of fossil is Tortoisegit/svn/hg on Windows. Worth every penny.

[magic]

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

[brucehoult]

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.

[bd139]

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.

[brucehoult]

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%...

[techman-001]

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

I sympathize completely and I'd send you a nice cuddly stuffed Fossil mascot to hug in your safe space if I could 

I can only imagine your anger as you read thru the Fossil treatise on REBASING and encountered statements such as "Rebasing is the same as lying" or "Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative."

What's really scary is the possibility that one day GIT might fix their weak history display capabilities and give their users the ability to switch back and forth between those instances where a simplified display is desirable and edifying and one showing the real, complete, messy history for cases where detail and accuracy are more important ?

My opinions only and you know I always enjoy your posts