On 14/03/15 05:20, Warren Young wrote:
On Mar 13, 2015, at 4:22 PM, Graeme Pietersz <gra...@pietersz.net> wrote:
On 14/03/15 03:01, Warren Young wrote:
I believe that once you extract the hosting services from the comparison,
Fossil comes out quite a bit ahead of Git.
Even without hosted services, Git still has integration with the likes of Trac
and Redmine, and , as James Moger pointed out, things like Gitlab, all of which
you can host yourself.
Yes, and you’re going to find out that setting them up is quite a lot more
difficult than setting up Fossil.
Having set up Trac once, I am very much aware of that. I did say that
the trade-off is more work to set up vs a more user friendly system once
set up.
You’re trying to compare a hosted service, staffed by a full-time set of
sysadmins and designers and such to Fossil. It would be just as unfair to try
to compare ChiselApp to some Git+Trac+MediaWiki lash-up.
Why would you need Media Wiki? Trac has a wiki, and it can host multiple
repos (albeit with no way of giving users different access to different
projects). Redmine can do the same without that limitation. I have not
looked at Gitlab etc. properly, but they also all seem to have those
features.
Why is it a lash-up? Trac now officially supports Git, so does Redmine.
Things like Gitlab and Gitblit obviously do. Comparing ChiselApp (unless
its improved a lost since the last time I used it) to Git + Trac, the
latter has a better issue tracker and wiki (because the ChiselApp
equivalents are just the Fossil ones). Git has 1) multiple hosted
services better than ChiselApp *and* 2) multiple issue tracker + wiki
web apps you can install yourself that are better than those that come
with Fossil *and* 3) the web apps are better than ChiselApp bar the
initial trouble of installing and configuring them.
It is not a matter of blame, but of a real disadvantage.
More like a trade-off, I think.
If X has a feature that Y does not it is a disadvantage, not a trade
off. For me, it rules out using Fossil tickets as a way of clients
reporting issues.
ChromeOS seems to be rather an odd choice for a development machine
Mostly I did it just to see if it could be done, but Scott’s right, it makes a
fine self-contained offline-editable wiki.
Another practical use is on a Chromebook set up with Crouton [1] where actual
software development and such takes place inside the chroot box, but you
maintain a separate clone of the software repo outside the box on the ChromeOS
side for answering tech support questions when you don’t want to bother firing
up Crouton.
Crouton looks very useful, and that is a good use case for using
something that is simple to compile. Personally I would probably just
install Ubuntu and use it, but that is a matter of personal preference.
You build the fossil binary while inside the chroot box, then scp it out before
shutting Crouton down. Crouton + Ubuntu ends up being a cross-compilation
environment for ChromeOS.
And yes, I have used a Chromebook + Crouton for actual software development.
For $200 and 3 pounds in my EDC bag, it’s a fine setup for cases where I don’t
want to drag along the full-size laptop.
To do better than a standard Chromebook for weight and size, you have to pay
many times more for a Pixel or the new MacBook Nothin’.
[1] https://github.com/dnschneid/crouton
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
