Fossil SCM(fossil-scm.org)
fossil-scm.org
Fossil SCM
https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
146 comments
This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.
I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.
Maybe this is to do with our desire for everything to be as flexible as the programming languages we write in. Most people don't view computers as blank slates ready to do their bidding, but as systems where the behaviour of a few facets is to be memorised without concerns for their mechanics or abstractions. This is probably one of the reasons that mobile software is seen as so easy to use, since it obscures/abstracts elements like the filesystem from the user.
Glad to hear Fossil is friendlier.
EDIT: I should say that I am a heavy user of Vim, Emacs, Git and Arch Linux, I am just saying that these tools often require a large up front investment, and this can be detrimental as well as sensible.
I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.
Maybe this is to do with our desire for everything to be as flexible as the programming languages we write in. Most people don't view computers as blank slates ready to do their bidding, but as systems where the behaviour of a few facets is to be memorised without concerns for their mechanics or abstractions. This is probably one of the reasons that mobile software is seen as so easy to use, since it obscures/abstracts elements like the filesystem from the user.
Glad to hear Fossil is friendlier.
EDIT: I should say that I am a heavy user of Vim, Emacs, Git and Arch Linux, I am just saying that these tools often require a large up front investment, and this can be detrimental as well as sensible.
> This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.
This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.
This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.
I think that's a bit unfair. It presumes git is trying to abstract it's internals in the first place.
It's not.
Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.
This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.
The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.
Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.
All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.
As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).
It's not.
Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.
This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.
The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.
Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.
All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.
As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).
> They're quite thorough (though they have the fault of being heavily steeped in git jargon).
So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that.
I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.
So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that.
I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.
> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.
While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware. Emacs, for instance, is not difficult to use, it is a different computing environment, which, when you get hold of it, can boost your productivity. I've written many little programs in it that I use every day which I'd never be able to write in other languages because a) I need to know at least one GUI framework and many other libraries, b) no other environment has the same use-hack-eval-use development experience, and c) the way you create GUIs in Emacs is so effective (mixture of special-mode, plain text and text with properties attached; all buffer-manipulation commands come in to your app out of nowhere, gratis) that one can set sth. working in their first hacking session, and then on improve their tools while using it, all interactive, whereas in all other GUI frameworks you're left alone with widgets and a dev cycle that's nearly always approximately write-compile-debug-compile.
Git, instead, is a plain tool for one purpose with an arcane user interface. I believe the patch theory school of VCS tools (e.g. darcs) will overtake in future when they'll smooth out their rough edges as they provide a very intuitive way to work with code as a series of related changes.
While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware. Emacs, for instance, is not difficult to use, it is a different computing environment, which, when you get hold of it, can boost your productivity. I've written many little programs in it that I use every day which I'd never be able to write in other languages because a) I need to know at least one GUI framework and many other libraries, b) no other environment has the same use-hack-eval-use development experience, and c) the way you create GUIs in Emacs is so effective (mixture of special-mode, plain text and text with properties attached; all buffer-manipulation commands come in to your app out of nowhere, gratis) that one can set sth. working in their first hacking session, and then on improve their tools while using it, all interactive, whereas in all other GUI frameworks you're left alone with widgets and a dev cycle that's nearly always approximately write-compile-debug-compile.
Git, instead, is a plain tool for one purpose with an arcane user interface. I believe the patch theory school of VCS tools (e.g. darcs) will overtake in future when they'll smooth out their rough edges as they provide a very intuitive way to work with code as a series of related changes.
Emacs is not difficult to use?
In order to get it to do half of what Notepad++ or Sublime or Kate do, you have to spend hours and hours to learn it and configure it in the hope that the investment will pay off and that the productivity gain will make up for it. And despite what you might say there's no data you can point me to that actually proves those increased productivity claims.
In order to get it to do half of what Notepad++ or Sublime or Kate do, you have to spend hours and hours to learn it and configure it in the hope that the investment will pay off and that the productivity gain will make up for it. And despite what you might say there's no data you can point me to that actually proves those increased productivity claims.
You are comparing Emacs with Notepad++. You are then not using Emacs as it's supposed to be.
The actual power of Emacs is realized once you learn elisp. Coding, documenting, commiting, blogging, browsing, file/dir manipulation, etc. all can be done efficiently using the same familiar buffer editing philosophy within Emacs.
The actual power of Emacs is realized once you learn elisp. Coding, documenting, commiting, blogging, browsing, file/dir manipulation, etc. all can be done efficiently using the same familiar buffer editing philosophy within Emacs.
> In order to get it to do half of what Notepad++ or Sublime or Kate do
Do they have anything remotely like Gnus or Org-mode? Tramp? Magit? VC mode? SLIME? EMACS IS NOT A TEXT EDITOR. It is a Lisp interpreter with many applications written in it which happens to have a text UI and a text editor in its standard distribution.
Do they have anything remotely like Gnus or Org-mode? Tramp? Magit? VC mode? SLIME? EMACS IS NOT A TEXT EDITOR. It is a Lisp interpreter with many applications written in it which happens to have a text UI and a text editor in its standard distribution.
Would you mind sharing what some of these little programs do?
A little thing to show a compact weather forecast [1], a basic fronted to FreeBSD pkgng, a frontend to zx2c4's pass, some other utilites.
[1] http://www.gkayaalp.com/emacs.html#forecast.el
[1] http://www.gkayaalp.com/emacs.html#forecast.el
> I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.
Some of us never forget. And "esoteric" is way to kind a word for that thing, it is abstraction leak made software.
Some of us never forget. And "esoteric" is way to kind a word for that thing, it is abstraction leak made software.
> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs)
No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.
No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.
Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) mean that git gets useful new features?
Yes?
Having checkout handle creating branches is strictly a shortcut. The other option for the shortcut would be for `git branch` to sometimes alter state in your working directory (it currently never does this). The non-shortcut version (which works today) is to only create branches with `git branch` and only checkout branches with `git checkout`.
If you look at it from the perspective of "checkout is the thing that screws with your local working directory", it is organized logically.
Having checkout handle creating branches is strictly a shortcut. The other option for the shortcut would be for `git branch` to sometimes alter state in your working directory (it currently never does this). The non-shortcut version (which works today) is to only create branches with `git branch` and only checkout branches with `git checkout`.
If you look at it from the perspective of "checkout is the thing that screws with your local working directory", it is organized logically.
> Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes)
Branch management:
> mean that git gets useful new features?
I don't really understand what you mean by this. Is something only 'powerful' if it 'gets useful new features'?
--
I'm not saying it's easy for newcomers, I'm just saying the difficulty is biased to the early stages of the learning curve (I certainly experienced it, I used to fear git - now I fear lack of it) and disputing the claim that it isn't powerful.
Branch management:
# creation
git branch foobar
# listing
git branch
# renaming
git branch -m barfoo
# relocation
git branch -f barfoo
# deletion
git branch -d barfoo
# change WD to branch
git checkout foo
# change WD to state of HEAD
git checkout -- .
# change WD to new branch forking HEAD
git checkout -b bar
# ...
> mean that git gets useful new features?
I don't really understand what you mean by this. Is something only 'powerful' if it 'gets useful new features'?
--
I'm not saying it's easy for newcomers, I'm just saying the difficulty is biased to the early stages of the learning curve (I certainly experienced it, I used to fear git - now I fear lack of it) and disputing the claim that it isn't powerful.
I think we're mostly in violent agreement that there's a pretty steep learning curve. That is also true for some other tools. I'm questioning the link between steep curve and powerful; it is true that many powerful tools have steep learning curves; but one can easily think of tools that have steep learning curves but are not powerful. So, the question is: is git's CLI just weird, or does it need to be weird in order to be successful as an SCM? (I think it's the former.)
It sounds like you are suffering from the problem yourself.
[deleted]
We've been using it as well for at least three years. I can get stuff done with fossil without having to read man pages and search for examples every time I'm doing something different. It's also suitable for teams that require a central repo as everything could be kept in sync with upstream with the added ability of hassle free branching and merging (svn I am looking at you), stashes and other git-like goodies.
The only problem is that once the history gets big enough, fossil gets slow. Everything is replicated everywhere which is an advantage (backups everywhere) but also a drawback (slow). I once tried to convert the FreeBSD ports tree to fossil and gave up after some hours and gigs of data.
Mercurial was interesting and user friendly as well, but it requires python. Fossil is a single self contained binary with everything in it. And so is the repo - a single SQLite database. No .svn dirs scattered all over the place.
The only problem is that once the history gets big enough, fossil gets slow. Everything is replicated everywhere which is an advantage (backups everywhere) but also a drawback (slow). I once tried to convert the FreeBSD ports tree to fossil and gave up after some hours and gigs of data.
Mercurial was interesting and user friendly as well, but it requires python. Fossil is a single self contained binary with everything in it. And so is the repo - a single SQLite database. No .svn dirs scattered all over the place.
if the workflow magically avoids conflicts, why not give them 2 commands to update/commit&push and keep all the power of git to who need it?
also, you do know that conflicts are going to show up eventually right?
also, you do know that conflicts are going to show up eventually right?
> if the workflow magically avoids conflicts, why not give them 2 commands to update/commit&push
The workflow doesn't avoid conflicts.
> keep all the power of git to who need it
Git provides no useful features over Fossil for what we're doing.
> you do know that conflicts are going to show up eventually right
And when they show up with Git, boy do they show up.
The workflow doesn't avoid conflicts.
> keep all the power of git to who need it
Git provides no useful features over Fossil for what we're doing.
> you do know that conflicts are going to show up eventually right
And when they show up with Git, boy do they show up.
Fossil is the SCM I always wish I were using, but for the benefit of external collaborators, I stick with Git and GitLab (previously, GitHub). Fossil is a lovely, small piece of software that does exactly what I want in a nice and simple way. It's fast and uses SQLite for everything, making it easy to programmatically extend it and munge its internal data.
Yeah, I feel exactly the same way. For me, the turning point was discovering hg-git, which allows me to use hg as a git client; so I get all the network effects of GitHub but without needing to, you know, actually have to use git.
But I still miss Fossil. I like the simplicity, and the feature set (although last I looked it still didn't do rename tracking), and the immutable nature of the database... I particularly liked the way that it's also a webserver. Being able to have your project web in a branch and when you want to make it live you just atomically update a tag is beautiful.
The wiki I never used much, preferring to use manually version-controlled markdown files instead. The bug tracker... actually works pretty well, but it needs a lot of setup before it looks and feels anything other than ropy. (Although this may have changed. When I stopped following fossil it was undergoing a big UI overhaul.)
If it supported bidirectional git sync, I'd switch back in a heartbeat.
Update: having just fetched the latest version from Debian, there's lots of new stuff. 'fossil fusefs' lets you mount the repository as a read-only filesystem, which is cool. There's better support for private branches. There's a monster machine-readable interface based around json data packets. You can now have unversioned but synced files? Possibly this is for big binaries where you don't care about history? There's a 'fossil stash'. There's full-text search. You can export bundles of changesets so you can pass them around (pull requests, basically).
Oh, and 'fossil praise' and 'fossil blame' are synonyms.
It looks like there is support for git bidirectional sync, but it looks a bit hacky:
https://www.fossil-scm.org/fossil/artifact/027298d991dec3a7
But I still miss Fossil. I like the simplicity, and the feature set (although last I looked it still didn't do rename tracking), and the immutable nature of the database... I particularly liked the way that it's also a webserver. Being able to have your project web in a branch and when you want to make it live you just atomically update a tag is beautiful.
The wiki I never used much, preferring to use manually version-controlled markdown files instead. The bug tracker... actually works pretty well, but it needs a lot of setup before it looks and feels anything other than ropy. (Although this may have changed. When I stopped following fossil it was undergoing a big UI overhaul.)
If it supported bidirectional git sync, I'd switch back in a heartbeat.
Update: having just fetched the latest version from Debian, there's lots of new stuff. 'fossil fusefs' lets you mount the repository as a read-only filesystem, which is cool. There's better support for private branches. There's a monster machine-readable interface based around json data packets. You can now have unversioned but synced files? Possibly this is for big binaries where you don't care about history? There's a 'fossil stash'. There's full-text search. You can export bundles of changesets so you can pass them around (pull requests, basically).
Oh, and 'fossil praise' and 'fossil blame' are synonyms.
It looks like there is support for git bidirectional sync, but it looks a bit hacky:
https://www.fossil-scm.org/fossil/artifact/027298d991dec3a7
SQLite usage makes me wonder how will it behave over time with millions of commits. Also makes me wonder how will it handle distribution.
There's a writeup here about scaling issues in moving NetBSD pkgsrc to Fossil:
http://fossil-scm.org/index.html/event?name=be8f2f3447ef2ea3...
But that was, like, 2011, so I have no idea if it's still valid or not.
http://fossil-scm.org/index.html/event?name=be8f2f3447ef2ea3...
But that was, like, 2011, so I have no idea if it's still valid or not.
To be honest, I'm very wary of using SQLite for storage for anything long term. Over the years I've had a few SQLite databases become corrupt in various software I use. Always a headache.
SQLite has had corruption bugs but they have been exceeding rare. Far more often it has been other factors that caused SQLite to become corrupt (ie it is a victim not the cause).
https://www.sqlite.org/howtocorrupt.html
https://www.sqlite.org/testing.html
https://www.sqlite.org/howtocorrupt.html
https://www.sqlite.org/testing.html
Just curious, were you running with ECC RAM on the box?
Indeed, what are the consequences of that choice, vs. git and hg?
I switched from Mercurial to Fossil for my personal projects about two years ago and have been very happy with it so far. (Not that I think Mercurial is bad, not at all).
The builtin Wiki was what really sold me on it, because it makes a great place to gather notes and such.
This is one nice piece of software, at least for my needs.
The builtin Wiki was what really sold me on it, because it makes a great place to gather notes and such.
This is one nice piece of software, at least for my needs.
I would also like to mention ChiselApp ( http://ChiselApp.com/ ) offers free Fossil hosting. I run this service, originally run and created by James Turner.
Thank you super much!
For me, the ease of self-hosting my own source-code hub tipped the balance in favor of Fossil SCM, after I abandoned Subversion. Ironically, the difficulty of self-hosting Git was the raison d'être for why inherently centralized services such as Github/Gitlab/etc were created in the first place, despite all the nice talk about distributed systems. There is no a priori reason why hosting a source code repo should be any different from hosting any random blog page. And Fossil is the proof that it can work.
I tried using Fossil as a DVCS/Project management tool for a class I'm currently teaching - but in the end I couldn't quite figure out self-registration combined with allowing authenticated push in a way that worked for ~25 students without needing much instruction/hand-holding.
If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up using gogs: https://gogs.io/
I'm not certain I actually prefer gogs to fossil, but apart for working as I wanted/needed without much setup it had the dubious benefit of forcing me to teach my students to use git, along with a rather cumbersome pull-request system (gogs tend to hickup on commits that probably should've been possible to fast-forward, possibly due to not forcing git to ignore white-space).
Dubious because as a bit of a mercurial fanboy, I think git has a frustrating and opaque command line interface, not helped by the fact that a standard workflow uses various "non standard" (as in: the most obvious) commands. Benefit because learning git is unquestionably a valuable skill, due to the popularity git enjoys, in no small part due to github's success.
I'd like to go back and revisit Fossil at a later time, but right now I'll probably spend any time I can find on (investigating) migrating from gogs to gitlab -- as it's turned out that the limits on pull-requests in gogs make it complicated to use with large groups of people new to version control.
That said, I'm a strong believer in combining wiki, version control and issues in a single repository supporting various DVCS workflows.
If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up using gogs: https://gogs.io/
I'm not certain I actually prefer gogs to fossil, but apart for working as I wanted/needed without much setup it had the dubious benefit of forcing me to teach my students to use git, along with a rather cumbersome pull-request system (gogs tend to hickup on commits that probably should've been possible to fast-forward, possibly due to not forcing git to ignore white-space).
Dubious because as a bit of a mercurial fanboy, I think git has a frustrating and opaque command line interface, not helped by the fact that a standard workflow uses various "non standard" (as in: the most obvious) commands. Benefit because learning git is unquestionably a valuable skill, due to the popularity git enjoys, in no small part due to github's success.
I'd like to go back and revisit Fossil at a later time, but right now I'll probably spend any time I can find on (investigating) migrating from gogs to gitlab -- as it's turned out that the limits on pull-requests in gogs make it complicated to use with large groups of people new to version control.
That said, I'm a strong believer in combining wiki, version control and issues in a single repository supporting various DVCS workflows.
Glad to hear you're considering using GitLab. We have an importer for Gitea but not for Gogs https://docs.gitlab.com/ee/workflow/importing/README.html so I think you might consider a batch import https://docs.gitlab.com/ce/raketasks/import.html
I just started using this yesterday!
I setup a personal Gitea instance on Linode, but wanted to make sure I could easily back up my repos in case I ever lose access or stop maintaining my personal Linode server.
Gitlab made it easy to setup all of my repos to mirror and automatically update from my Gitea daily.
(One slight bug, Gitlab does seem to always say the repos failed to import, even when they're successful)
Thanks for the helpful feature!
I setup a personal Gitea instance on Linode, but wanted to make sure I could easily back up my repos in case I ever lose access or stop maintaining my personal Linode server.
Gitlab made it easy to setup all of my repos to mirror and automatically update from my Gitea daily.
(One slight bug, Gitlab does seem to always say the repos failed to import, even when they're successful)
Thanks for the helpful feature!
Great to hear you're using GitLab already. Please consider creating an issue for the 'repos failed to import, even when they're successful' that allows us to reproduce it.
Thank you for the tip about gitea, which appears to be a fork of gogs:
https://blog.gitea.io/2016/12/welcome-to-gitea/
I'll check that out first I think - I really like the ease of deployment with gogs, so if the project have some features a little more ironed out - it might be just what I need.
https://blog.gitea.io/2016/12/welcome-to-gitea/
I'll check that out first I think - I really like the ease of deployment with gogs, so if the project have some features a little more ironed out - it might be just what I need.
If anyone is interested in some of the deeper rationale behind SQLite and such, the FLOSS Weekly episode on this was pretty good.
https://twit.tv/shows/floss-weekly/episodes/320
https://twit.tv/shows/floss-weekly/episodes/320
The previous submission of the link to fossil-scm.org ( https://news.ycombinator.com/item?id=12673229) has some interesting comments from the creator.
My god, they've updated the CSS. It used to be quite a bit uglier. Now it's not GitHub, but it's definitely lighter on the eyes.
Nice to see - I think that good tools should have UIs that at least come close to the quality of their engineering.
Nice to see - I think that good tools should have UIs that at least come close to the quality of their engineering.
While it's good to have a pleasant default, it's very easy to modify everything about the website, including the CSS, the menu, the homepage...
But to me, the most beautiful UI is one that offers the functionality I need while remaining lightweight.
But to me, the most beautiful UI is one that offers the functionality I need while remaining lightweight.
I remember the old page / look and I feel like that one had much more character. This kind of design is very generic and has been for quite some years now.
Podcast with the creator of SQLite who also created Fossil, they also talk about the latter. Definitely recommended.
https://changelog.com/podcast/201
https://changelog.com/podcast/201
GitLab contributors, please take note.
Fossil's UI is very fast and the navigation is intuitive and discoverable.
I know it's on the roadmap, but it is so often an afterthought.
Fossil's UI is very fast and the navigation is intuitive and discoverable.
I know it's on the roadmap, but it is so often an afterthought.
Thanks, we're indeed working on making the UI faster in https://about.gitlab.com/2017/02/06/vue-big-plan/
I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation:
1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something.
2. Fossil timeline seems similar to GitLab Activity https://gitlab.com/gitlab-org/gitaly/activity
3. Fossil code seems similar to GitLab Repository https://gitlab.com/gitlab-org/gitaly/tree/master
4. Fossil docs seems similar to GitLab help https://gitlab.com/help (in this case, for other projects I think it has the documentation of the project, not sure what standard they use)
5. Fossil branches are in the GitLab repo view
6. Fossil tickets are similar to the GitLab issues view
7. Fossil wiki is similar to GitLab wiki
8. Fossil includes a download tab, in GitLab that would be the tags view https://gitlab.com/gitlab-org/gitaly/tags to download the repo (not sure if this is always to download Fossil or the specific project)
9. The Fossil "More..." link looks like a sitemap.
What would you change in GitLab to make it more discoverable?
I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation:
1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something.
2. Fossil timeline seems similar to GitLab Activity https://gitlab.com/gitlab-org/gitaly/activity
3. Fossil code seems similar to GitLab Repository https://gitlab.com/gitlab-org/gitaly/tree/master
4. Fossil docs seems similar to GitLab help https://gitlab.com/help (in this case, for other projects I think it has the documentation of the project, not sure what standard they use)
5. Fossil branches are in the GitLab repo view
6. Fossil tickets are similar to the GitLab issues view
7. Fossil wiki is similar to GitLab wiki
8. Fossil includes a download tab, in GitLab that would be the tags view https://gitlab.com/gitlab-org/gitaly/tags to download the repo (not sure if this is always to download Fossil or the specific project)
9. The Fossil "More..." link looks like a sitemap.
What would you change in GitLab to make it more discoverable?
The Fossil timeline view is helpful because of the actual line(s) that are drawn for each branch -- it's a visualization tool rather than a log of commits. This seems to be lacking in the linked "GitLab Activity" view.
Also handy is the Fossil timeline includes more than just commits, it includes Commits, Wiki changes, Change artifacts, Technotes, and ticket creation/updates so you can get a sense of how things happened in time.
Also, Fossil supports serving multiple repositories -- it's just a matter of how you start it, but since it's all integrated there's not a lot of reason to use that functionality usually. ChiselApp uses Flint ( https://chiselapp.com/user/rkeene/repository/flint/ ) to handle the administrative task of creating repositories, taking in repositories as uploads, resetting repository passwords if you have access to the ChiselApp dashboard, and performing scheduled pulls.
Also handy is the Fossil timeline includes more than just commits, it includes Commits, Wiki changes, Change artifacts, Technotes, and ticket creation/updates so you can get a sense of how things happened in time.
Also, Fossil supports serving multiple repositories -- it's just a matter of how you start it, but since it's all integrated there's not a lot of reason to use that functionality usually. ChiselApp uses Flint ( https://chiselapp.com/user/rkeene/repository/flint/ ) to handle the administrative task of creating repositories, taking in repositories as uploads, resetting repository passwords if you have access to the ChiselApp dashboard, and performing scheduled pulls.
The issue is not that Gitlab is missing any of the pieces. The issue, I believe, is the organization of such pieces so that you can find them intuitively.
This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon for each of the basic concepts. A "project" is a "repository" and a "group" is an "organization", etc. I can kind of grok it, but I sometimes do a double take when something isn't where I expect.
For example: In my mental model, "project" == "repository". But when I go to a project home page like say [1], I don't see a code browser or commit list, or options that obviously take me to either of those. Instead, I have to click the "Repository" tab first. (It turns out that tabs can have second-level tabs, which means those options are hidden initially and thus not discoverable.) But I thought a "project" was a "repository"?
I fully realize the Gitlab notion of "project" may be more general than just a "repository", but this is an example of the sort of cognitive dissonance that I get navigating around the site.
At this point I've mostly made peace with the Gitlab interface, so it's a bit hard for me to pull up examples like this now. And as I said above, the interface has improved. But when I first started using Gitlab, there were a lot of things like this (little points of cognitive dissonance) which made it seriously an uphill battle to even use the product.
[1]: https://gitlab.com/StanfordLegion/legion
This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon for each of the basic concepts. A "project" is a "repository" and a "group" is an "organization", etc. I can kind of grok it, but I sometimes do a double take when something isn't where I expect.
For example: In my mental model, "project" == "repository". But when I go to a project home page like say [1], I don't see a code browser or commit list, or options that obviously take me to either of those. Instead, I have to click the "Repository" tab first. (It turns out that tabs can have second-level tabs, which means those options are hidden initially and thus not discoverable.) But I thought a "project" was a "repository"?
I fully realize the Gitlab notion of "project" may be more general than just a "repository", but this is an example of the sort of cognitive dissonance that I get navigating around the site.
At this point I've mostly made peace with the Gitlab interface, so it's a bit hard for me to pull up examples like this now. And as I said above, the interface has improved. But when I first started using Gitlab, there were a lot of things like this (little points of cognitive dissonance) which made it seriously an uphill battle to even use the product.
[1]: https://gitlab.com/StanfordLegion/legion
Thanks for the response, and I'm glad that it is better than it used to be.
In GitLab people can have a project without a repository, for example with just a wiki or an issue tracker. For that reason we use different words for it.
Single people also use GitLab as a single tenant we prefer to use the word group over organization. That will also fit better when we introduce nested groups in GitLab 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
Good point about showing files by default, we're discussing that in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834
Thanks for using GitLab!
In GitLab people can have a project without a repository, for example with just a wiki or an issue tracker. For that reason we use different words for it.
Single people also use GitLab as a single tenant we prefer to use the word group over organization. That will also fit better when we introduce nested groups in GitLab 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
Good point about showing files by default, we're discussing that in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834
Thanks for using GitLab!
Thanks for the open discussion!
As eslaught pointed out, it's not about the obvious mistakes.
Unfortunately, the navigation is very fragmented. There's a left menu, which should be the primary one, but it changes all the time depending on the context.
The top menu is very inconsistent, presented in multiple layers, with different styles for each level, using very low contrast text with no other visual aid. There are no dropdowns or other ways to get to frequented pages faster. Being aligned to center also prevents me from memorizing the UI spatially (YMMV).
And there's also the issue with minimalistic buttons acting like links.
It is my humble opinion that rewriting the frontend in Vue will not, by itself, alleviate the matter; however, fixing this part of the UX will make GitHub and Atlassian really run for their money.
As eslaught pointed out, it's not about the obvious mistakes.
Unfortunately, the navigation is very fragmented. There's a left menu, which should be the primary one, but it changes all the time depending on the context.
The top menu is very inconsistent, presented in multiple layers, with different styles for each level, using very low contrast text with no other visual aid. There are no dropdowns or other ways to get to frequented pages faster. Being aligned to center also prevents me from memorizing the UI spatially (YMMV).
And there's also the issue with minimalistic buttons acting like links.
It is my humble opinion that rewriting the frontend in Vue will not, by itself, alleviate the matter; however, fixing this part of the UX will make GitHub and Atlassian really run for their money.
Thanks for your feedback! This will an is becoming more and more a focus for us!
To join the discussion see: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348#note_23... or https://gitlab.com/gitlab-org/gitlab-ce/issues/18844#note_23...
To join the discussion see: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348#note_23... or https://gitlab.com/gitlab-org/gitlab-ce/issues/18844#note_23...
Thanks for the advise, I passed it on to our UX team. I agree that rewriting in Vue is just an element of having a good interface and that the menu itself is very important too.
I've been using GitLab for a couple of years now and it's true that finding stuff is not very intuitive. Even now I still have trouble finding things. Maybe you should watch many new people using it to see where they get stuck.
I couldn't find any screenshots on the site, can you share any?
Just click the link above, the entire site is Fossils interface.
I believe the site itself is running an instance of Fossil?
Yep. Cloning it is also a great way to poke around and get a better sense of its functionality.
Surprised to see no LDAP support.
http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8
http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8
Fossil can work over HTTP or SSH. Over HTTP you can authenticate using any method your web server supports, or the built-in Fossil authentication. For SSH, you can authenticate using any method your SSH server supports.
From what I can tell from the issue, they're suggesting the load balancer or server you put in front of Fossil to do the authentication (which can hit LDAP/AD).
Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.
Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.
You can sort-of hack it together offline, in that LDAP can be the source of identity (via REMOTE_USER + frontend, as you mention), and that Fossil has a reasonably fine-grained permissions model that you can (offline) sync from LDAP.
> Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.
That seems like a terrible compromise.
That seems like a terrible compromise.
I am huge fan of fossil and using it for my side projects , I also wrote a blog about it https://fulstacker.wordpress.com/2016/04/11/all-you-need-to-... . I am working on a React.JS Angular implementation of Fossil which is still in its primitive stage. I plan to open source it some day !
I use Fossil whenever I can. Unfortunately, this means I have only ever used it for projects where I'm the only contributor.
It's good to see so many SCM systems showing up. But it makes me wonder how many of them can actually work on GBs of codebase with over 1000 of programmers checking in on daily basis. I my experience most of SCMs are fine for small to medium projects, but they go down with crawling speeds and sometimes even not working at all when it goes large scale.
Hmm, really?
It's hard to measure objectively... but my perception was always that there was an explosion of SCMs around the early-mid 2000s, after everybody got sick of CVS, but eventually Git won out and a lot of the alternatives / diversity in the space went away.
Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar, Mercurial. On the commercial side, perforce had a certain amount of traction, and the Linux kernel was using BitKeeper... which no doubt encouraged a lot of the innovation in the open-source space.
Then, once Git was developed, got huge exposure and traction through the Kernel, and GitHub came onto the scene, it quickly became dominant - despite the alternatives, and despite the goofy interface.
It's hard to measure objectively... but my perception was always that there was an explosion of SCMs around the early-mid 2000s, after everybody got sick of CVS, but eventually Git won out and a lot of the alternatives / diversity in the space went away.
Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar, Mercurial. On the commercial side, perforce had a certain amount of traction, and the Linux kernel was using BitKeeper... which no doubt encouraged a lot of the innovation in the open-source space.
Then, once Git was developed, got huge exposure and traction through the Kernel, and GitHub came onto the scene, it quickly became dominant - despite the alternatives, and despite the goofy interface.
I firmly believe that GitHub has at least 40% role in git's success. Another 40% is Linus, and the remaining 20% is git's technical merits.
Sounds about right to me... but it's hard to decouple things so neatly. It wouldn't really be possible to create an SVNHub that worked as well as github.
Before everyone got onto GitHub, there was SourceForge and GoogleCode. Both worked well for a lot of people for quite some while.
Also, if you really want to, you can use the SVN interface of GitHub and never go through git. You could, in its time, also use Google code with git repositories but without the pileup if nice little things that make GitHub more than just a git hosting service
wrt SVNHub, well, probably you're right. But on the technical level any <insert your DVCS>Hub would be at least nearly as good as GitHub. And git didn't invent DVCS.
SVN is still quite popular. I'd definitely not bundle it with Arch, Darcs, Quilt or Bazaar, in that regard ;)
Fossil is not really built with that development model in mind. It's built for development of sqlite, which has a small group of core developers that know each other.
Richard Hipp explains the target market at the beginning of this video: https://www.youtube.com/watch?v=-ceEWWqaVsI
Richard Hipp explains the target market at the beginning of this video: https://www.youtube.com/watch?v=-ceEWWqaVsI
It's been working really well for Tcl development as well. Tk, and many other Tcl extensions as well.
I tried to ask a couple of days ago if anybody has started using bitkeeper lately but either only one person saw it or only one other person found it interesting:
https://news.ycombinator.com/item?id=13661662
https://news.ycombinator.com/item?id=13661662
I missed that, but I'm interested in the answer too. I believe the bitkeeper guy frequents this forum. Haven't tried it, myself.
Haven't tried it, myself.
Neither have I and I am a bit hesitant to throw all my tooling out of the window (ok, mostly hosted git + git extensions + builtin git + svn support in all my IDEs (Netbeans/VS/Rider).
Neither have I and I am a bit hesitant to throw all my tooling out of the window (ok, mostly hosted git + git extensions + builtin git + svn support in all my IDEs (Netbeans/VS/Rider).
Veracity is the only other SCM I know of that takes the distribute everything approach of Fossil. Are there any others?
haven't seen [veracity](http://veracity-scm.com/) mentioned in a while! I always thought the idea of using JS as the built in scripting/templating language was ahead of its time.
Fossil has TH1 -- pretty much a stripped down Tcl, but can also (optionally) call out to full Tcl.
I use Fossil for all my personal projects, and I use its wiki, technotes, and tickets for almost all of my knowledge and task management. It has become the centerpiece of my workflow. Where else have I seen as great a combination of reliability, simplicity, and flexibility? Oh yeah, SQLite. Thanks drh.
No/manual rebase sounds awful
From the git vs fossil faq:
"Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it not something that can be done with a single command."
https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
"Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it not something that can be done with a single command."
https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
1. Fossil is designed around having auditable history.
2. Fossil can change meta-information (commit messages, tags, branch names) after the fact. Those changes also leave an audit trail.
3. Fossil has features that handle certain use cases for rebasing (private branches, fossil stash snapshot, etc.). If you absolutely need to, fossil purge can be used to edit local history and the shun mechanism can be used to (e.g.) extirpate sensitive information that was shared by accident.
4. Extensive use of rebasing to produce a linear history is a Git-ism , largely due the fact that in Git, history is a soup of anonymous commit objects that is difficult to visualize. Other version control systems that allow you to label and structure history have less need for this.
2. Fossil can change meta-information (commit messages, tags, branch names) after the fact. Those changes also leave an audit trail.
3. Fossil has features that handle certain use cases for rebasing (private branches, fossil stash snapshot, etc.). If you absolutely need to, fossil purge can be used to edit local history and the shun mechanism can be used to (e.g.) extirpate sensitive information that was shared by accident.
4. Extensive use of rebasing to produce a linear history is a Git-ism , largely due the fact that in Git, history is a soup of anonymous commit objects that is difficult to visualize. Other version control systems that allow you to label and structure history have less need for this.
Genuinely curious: Why do you need rebasing?
I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
I end up using it when fixing up local changes which had broken due to upstream modifications.
It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon.
When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon.
When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
I used mq, and really liked it when I used it. Admittedly do not use it much any more (too lazy to do the extra typing).
If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development.
Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.
Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.
> If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits.
This is an artifact of Git. There are two principal solutions that do not require rebase.
1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history.
2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.
This is an artifact of Git. There are two principal solutions that do not require rebase.
1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history.
2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.
So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end?
As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
Git actually maintains the following:
Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact.
Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact.
Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
It will show them at the time they occurred, with an additional notation for when the rebase command recreated them.
On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.
On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.
> I don't understand how rebasing can be more complicated on Mercurial than Git.
It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
You have to enable the rebase extension (comes with Mercurial) and it is just
`hg rebase -s src -d dst`
`hg rebase -s src -d dst`
I use git rebase -i as a way to develop. If I make a series of changes and the middle one doesn't compile or I want to restructure things, I'll use git rebase -i. The outcome is a set of patches that a suitable to send out for review.
hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
Interesting: For the short time I used mq, I was quite impressed with the functionality - but did not use a GUI and eventually stopped using it because of the overhead in typing.
>Genuinely curious: Why do you need rebasing?
Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team).
Also, rewriting history (in the good sense of the term).
Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand.
For git, history is a tool for documenting the project -- and I love it.
Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team).
Also, rewriting history (in the good sense of the term).
Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand.
For git, history is a tool for documenting the project -- and I love it.
Rebasing gives you a linear history instead of the diamonds non-rebased branching and merging gives you. I mean, that's the technical reason, anyway.
But that's what I'm trying to understand: The branched history was never a problem for me (although I do use a GUI for it).
For me I dislike branched history because each merge point can (accidentally) have extra non-merge code added and therefore should technically be code-reviewed, too. Git doesn't like showing merge commit diffs (even with `git log -p`) and so it's not easy to see how someone resolved their merge conflicts.
I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
Usually as a way to ensure a working branch stays up to date with master/another branch, so there aren't merge conflicts. Or if there are merge conflicts, to resolve them.
I regularly need to apply patches written months/years ago to a branch that's changed many many times (maybe a thousand) - for example, patch written at a specific point in time spends 2 months being reviewed, and by that time it no longer cleanly applies to trunk.
Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk
Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk
It would be great to add Fossil, as another backend to RhodeCode VCSServer that now supports git, Mercurial and SVN.
It's also written in python so it should be not so hard.
It's also written in python so it should be not so hard.
Anyone using it for development? What is your experience?
I use fossil for all my projects. It's very lightweight and almost set it and forget it system. Remarkable.
I'm using it for a number of personal projects and a couple of projects with a small number of collaborators.
Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for.
Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.
Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for.
Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.
Numerical version numbers in Mercurial are a good thing until they start to differ in different repository copies, after which you have to educate everyone to refer to versions by their hash instead of the numeric version
1. You can use the Bzr approach instead, which has universally valid revision numbers.
2. Even local revision numbering has useful applications, such as annotate/blame, where numbers (unlike hashes) follow a chronological ordering. It is still better than not having them at all.
2. Even local revision numbering has useful applications, such as annotate/blame, where numbers (unlike hashes) follow a chronological ordering. It is still better than not having them at all.
I started to use it for one large project a few months back as I liked the idea of having an integrated issue tracker/docs/wiki/etc. In the end I wasn't a huge fan of fossil overall as its implementation felt clunky and I reverted back to git. I'd say most of it's problems can be attributed to a lack of polish due to the much smaller user base compared to other options like git.
What issues did you have ? Fossil is usually pretty easy to cleanup any dangling wires, if they can be coherently identified to people who may not see them in the same way as you.
It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes (git add -p and vim's git-fugitive options make the staging area hugely useful); attaching files to issues/wiki/etc was difficult; setting up a remote which could be pushed/pulled from (with multiple machines) was difficult; and I recall the username + password combo failing in a way that I never diagnosed.
Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
Many of these issues have likely been resolved.
Wiki supports the wiki format, markdown, and HTML now.
There is now a "fossil search" command for full-text search (including artifacts, if enabled).
I've never had a username/password failure so no idea what that could be.
For tickets, icomment is probably the solution you want but it's not very intuitive.
git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.
Wiki supports the wiki format, markdown, and HTML now.
There is now a "fossil search" command for full-text search (including artifacts, if enabled).
I've never had a username/password failure so no idea what that could be.
For tickets, icomment is probably the solution you want but it's not very intuitive.
git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.
I use it a lot. Here are many of my repositories:
http://chiselapp.com/user/rkeene/
I also use it for many non-public repositories, including the Linux distribution I maintain (with a few hundred packages).
My experience is that it is very convenient and easy to adapt.
I also use it for many non-public repositories, including the Linux distribution I maintain (with a few hundred packages).
My experience is that it is very convenient and easy to adapt.
I've used it quite a bit, and I'm happy with it. My main gripe (and it's not much of a gripe): editor integration. There's vc-fossil, but vc incompatibly changed its API between Emacs24 and Emacs25. While I generally don't like git very much, magit is amazing (and, honestly, the only reason I can put up with git).
I wish it supported AJAX and the client UI was decoupled from the repository.
I'm not sure I understand what you mean with "client UI being decoupled from the repository". Wouldn't everything you do in an SCM necessarily be coupled to a repository?
If you have multiple repositories, you have to set up the UI and ticketing setup in each one individually. (Although you can share a login database.)
I don't know if it's been fixed by now, but back when I was using Fossil regularly there were long-standing bugs where pushing the UI and ticket configuration from one repo to another didn't work properly, so synchronising look and feel across multiple repositories was hard.
I don't know if it's been fixed by now, but back when I was using Fossil regularly there were long-standing bugs where pushing the UI and ticket configuration from one repo to another didn't work properly, so synchronising look and feel across multiple repositories was hard.
Some parts of the UI do use AJAX -- the tree-style file browser, for example.
Too slow, tried to convert linux git repo to fossil but failed.
I absolutely love Fossil. And the author is a great guy! It never gets the press or usage it deserves.
Glad to see this come up on HN!
It came up on HN not long ago: https://news.ycombinator.com/item?id=12673229. Normally we'd bury this one
as a duplicate, but the community is clearly interested in this.
Fossil is running on https://www.sqlite.org/docsrc/artifact/c3a749450a2f0d73 .. another lovely piece of software .. like it
I dont see the point of Fossil, I looked into it. The commands arent that much easier to understand. If I'm using an SCM anyway and I still need to use a cmd line and I still need to memorize commands then I might just as well use git. And Git has Guis now.
Without having looked into the details... I do rather like the idea of an SCM with a built-in ticketing / documentation (wiki / markdown rendering system).
These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks.
It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.
These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks.
It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.
On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.
I disagree completely - I think these things have the same properties as source code.
Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
You might like https://github.com/brandonson/evict. I used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in a bad way. I've been meaning to switch to evict but haven't ever been able to get it to compile :-).
IIRC, ditz and evict and b-e and ticgit and... all don't solve a problem for public projects which fossil does: random people on the Internet need to be able to submit bug reports.
Because fossil comes with a web server and a wiki, there typically is one blessed instance for any project. That's not too weird; after all, that's basically true fro pretty much everything maintained on GitHub too -- the only difference is you get the issue tracker and wiki in the repo.
If for nothing else then at least some people like me find it awesome that some people can still put all this into a small standalone and make it work nicely under multiple operating systems.
Probably it's just me, but I could never wrap my head around git and gave up after a few attempts to get my feet wet with it.
With Mercurial and Fossil, they worked very intuitively for me.
Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts.
(I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)
With Mercurial and Fossil, they worked very intuitively for me.
Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts.
(I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)
The git UI is not necessarily consistent or pleasant. In many cases, this has improved over the years, but plenty of stuff still only makes sense via rote memorization, not because it actually matches what you're trying to do.
http://stevelosh.com/blog/2013/04/git-koans/
http://stevelosh.com/blog/2013/04/git-koans/
Fossil's emphasis on recording history is very helpful.
Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful.
Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository.
No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing)
I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams.
When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.
Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful.
Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository.
No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing)
I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams.
When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.
>No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required.
I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required.
I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
Fossil's default mode, autosync, is more closely modeled by: git pull && if stillCommitingToBranchTip; then git commit -a; else echo "Not committing to the tip of the current branch" >&2; false; fi && git push
You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area.
This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.
You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area.
This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.
That's true, but also means that there's a fake intermediate stage that never actually existed in the WT, and hence definitionally was never linted or tested.
Iep. Running the tests over the new commits before pushing is still required. Usually not a big problem.
Git has had several (first- and third-party) GUIs for a long time...
I switched to Fossil a few months ago. Nice website that holds all the information. fossil commit -m "Message" is all they need to know. If they forgot to pull, it stops and tells them to do so. They type fossil update and go on with their lives. Zero problems so far and a more productive workflow overall.