On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer <m...@mired.org> wrote:
well-balanced assessment.
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
from my recent experience , `autosync' seems to be _the_ feature making
the move to DVCS tolerable for some die-hard `svn' users.
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.
could you please elaborate on this? I came to fossil only very recently
and, for now,
have decided to keep the repo in the checkout directory (just like `hg',
say). if
I don't won't to have multiple checkouts from the same repo what's
potentially
bad about this setup? what kind of problems do you have in mind?
j.
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.
the NetBSD example seems to indicate that fossil's has performance problems
for such projects with a massive code base. is this still the state of
affairs?
not that this would matter for 99.9% of all projects.
j.
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
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
