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.
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.
.... Just to get an idea of the "popularity" of different VCS, ...
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
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.
Yeah. No private branching? No rebase?
Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?
Just remember in the world of the blind the one eyed man is king. This explains the entire of git's popularity. The people who "know git" are charlatans.
I don't know about those "charlatans" you are talking about.
I believe Linus when he says it outperforms all alternatives, wether it is price, speed, flexibility or integrity.
If I have to choose to believe you or Linus, I choose Linus
(no offence, I have high regards of you and most of the time I appreciate/agree what you are writing here).
Yeah. No private branching? No rebase?
Is there a way to run bisect on a fossil repo without building all the garbage broken commits stuck between the good ones which in git would be squashed with their predecessors, cleaned up, rebased and applied to master?
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!
Bisect is standard process in projects which take a few minutes tops to incrementally recompile
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
On top of that the Linux kernel team work completely different to most of the git users out there who centralise everything on github. Even Linus doesn't like github, rightfully stating the pull requests are wrong. Which they are!
I was talking about Git, not github (which I left almost the same day microsoft bought it).
I think we agree about Git != github.
Bisect is standard process in projects which take a few minutes tops to incrementally recompileThat doesn't make sense.
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
Bisect is standard process in projects which take a few minutes tops to incrementally recompileThat 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.
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.
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 GITI 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