On Tue, 18 Dec 2012 14:42:34 +0100 Gilles <gilles.gana...@free.fr> wrote: > Out of curiosity, if someone is well-versed with Fossil and the main > DVCS systems (Mercurial, Git),
Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. > Besides the fact that Fossil includes a wiki and a bug tracker, does > it offer features that would make it a better solution than the big > names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally "right", but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a "you can't change history" philosophy, except for the "rollback" command that lets you undo the last commit. I use "rollback" to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of "brain fart" protection you get from the hg "rollback" command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg "rollback" command. <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users