Earlier quoted context omitted.
I believe the site itself is running an instance of Fossil?
That's correct. Fossil is just a single binary and all the 'artifacts' in the repo are stored in a single sqlite file. The built-in server works really well or it can also be used with CGI.
Fossil SCM
41–50 of 147 posts
Re: Fossil SCM
#42Surprised to see no LDAP support. http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8
Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.
Re: Fossil SCM
#43It'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.
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
Re: Fossil SCM
#44Surprised to see no LDAP support. http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8
Re: Fossil SCM
#45Re: Fossil SCM
#46Anyone using it for development? What is your experience?
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.
Re: Fossil SCM
#47Earlier quoted context omitted.
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 underl…
> 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.
`hg rebase -s src -d dst`
Re: Fossil SCM
#48Veracity is the only other SCM I know of that takes the distribute everything approach of Fossil. Are there any others?
Re: Fossil SCM
#49The 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.
Re: Fossil SCM
#50I 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.
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.