Earlier quoted context omitted.
> Almost nobody uses just git -- they use github or gitlab. Your points are made in a needlessly provocative manner. Tons of people roll their own interfaces to their source control, and a lot of people benefit from somewhat centralized repositories. Not only is there room for both, but I don't see any data indicating how prevalent private, non-GitHub repositories are, or how those would even be counted accurately gi…
> Tons of people roll their own interfaces to their source control, And how do they compare with github's megatons? I argue the numbers are not comparable. My most generous estimate is that less than 5% of all git users work without ever touching Github. > Mercurial isn't as popular as git, but neither are dependent on GitHub/bitbucket for continued relevance. I am convinced that if anything ever replaces git, it wil…
Fossil SCM keeps more than just your code
41–50 of 91 posts
Re: Fossil SCM keeps more than just your code
#42Earlier quoted context omitted.
That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you. What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew. Nobody ne…
Why do you feel that you _have_ to be able to correct history? The past is immutable. Fossil treats it as such. git does not, no matter what configuration you're running - i can always create a fork, modify the history in my fork, and publish that. git has mutable history, period. fossil does not, period. They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of pe…
Why do you feel I shouldn't be able to do what I want with my history before others see it? Shared repos can reject history rewrites, as the parent said.
Also, as others have said, fossil does not provide the tools to mutate history, but that doesn't mean that history is immutable.
> They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of people who feel they need to retroactively cover up past mistakes.
Who's talking about mistakes? I'm talking about cleaning up a stream of small commits I've made over the day into a smaller number of coherent, sensible commits.
Re: Fossil SCM keeps more than just your code
#43Earlier quoted context omitted.
> What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
> Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability. I work for a company that builds machines to be sent into space (specifically, electronics and high-tech instruments), and I have never heard of such a requirement. The end result matters to our customers, not the thousands of commits in our Subversion repository.
Re: Fossil SCM keeps more than just your code
#44Earlier quoted context omitted.
> Almost nobody uses just git -- they use github or gitlab. I don't understand what you mean. I know plenty of people that simply use SSH or local-only repositories. If you intend on sharing said repo, github is essentially cheap shared hosting (or did you also complain that people didn't run their own httpd?).
I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?
Why must one have never used github while also not using github? I have many private repos I share amongst my machines, but I also publish projects on github when I want them to be public.
> Both Fossil and hg have an httpd built-in.
That seems horrible. Why do I want these features built in when they can be delegated to other applications (which I can choose among based on their features and not forced to use the one supplied?)
Re: Fossil SCM keeps more than just your code
#45I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or som…
Re: Fossil SCM keeps more than just your code
#46Earlier quoted context omitted.
> Tons of people roll their own interfaces to their source control, And how do they compare with github's megatons? I argue the numbers are not comparable. My most generous estimate is that less than 5% of all git users work without ever touching Github. > Mercurial isn't as popular as git, but neither are dependent on GitHub/bitbucket for continued relevance. I am convinced that if anything ever replaces git, it wil…
I'd say "users that never use Github, for anything" isn't a very useful measure. Yes, that number is very low, but I bet most of GitHub's users also have repos that do not exist on Github, or are only sent to GitHub as a mirror (because GitHub is where people search for code).
I'd say "users that never use Github, for anything"
isn't a very useful measure.
It is important because Github has become the yardstick by which everything else is measured. People expect git to work roughly like Github. The whole pull request workflow was popularised by Github. Linux and git do not use pull requests. The deprecation of the git:// uri scheme is also Github. The expectation of an integrated bug tracker, comment threads, and wiki is also Github.Re: Fossil SCM keeps more than just your code
#47However I got spoiled by the power of Git. So what I do now is to keep a TiddlyWiki[1] on the Git repo, so I have the best of both worlds.
Re: Fossil SCM keeps more than just your code
#48Earlier quoted context omitted.
It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.
> sort of like a TODO but with super-powers. Funnily enough our team just introduced an eslint warning ( https://github.com/eslint/eslint/blob/master/docs/rules/no-w... ) to discourage those TODO comments as we found they just always sat around forever collecting lint.
However, it is just as easy to have unloved, unwatched tasks festering in JIRA or Trac as it is to have TODOs festering in the source code. (I've seen both). The form in which the problem manifests itself isn't terribly important here ... or at least, its' less important than the solution.
What is needed is a robust and active process to triage new issues; to action items that really are a problem, and to record the decision to discard problems which are not worth resolving. If you have this process in place and working, then you don't need to care as much about where the tasks are stored: SQL database or text file or Excel spreadsheet ... all can be made to work.
Now, personally, I would argue that having a structured, human-readable and editable serialisation scheme, under version control and configuration management, usable for tasks, requirements and other items of engineering documentation will (does) make it easier to build the level of comprehensive scripting and automation that (I believe) is required for a truly disciplined engineering process.
Re: Fossil SCM keeps more than just your code
#49Earlier quoted context omitted.
What happens if you accidentially add code where you dont own the copyright? Or an API Secret? http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki
So… not that different from git after all? (rebasing creates new revisions, but while the old ones may not be trivially accessible anymore they're still there until garbage collected)
http://fossil-scm.org/xfer/doc/trunk/www/private.wiki
It's interesting how both Fossil and Mercurial (and others?) first took strong stances against "changing history" and then softened those stances over time.
Re: Fossil SCM keeps more than just your code
#50I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or som…
sigh, I miss the IDE days... you can say whatever you want about eclipse or svn, but... in those day I have a source tracker, a bug tracker, unit tests, a wiki internal doc all linked from eclipse; I got bug #ids, clicked on them, make my fix, test them, commit, etc... without miss the dots (in the commit message there was an autogenerated link to the bug, etc)