On 12/18/12 22:29, Mike Meyer wrote: [---] > 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.
I don't think "large team" is a problem, apart from the manual work required in setting up users. I did some work a while back gluing together fossil with a security middleware which has an integrated identity manager. It reused the identity manager to configure fossil server instances. I did some quick'n'dirty hacks; like opening up the repository via libsqlite and manipulated the databases directly, which didn't feel all too excellent. (Though the whole thing was a proof-of-concept and something to demo, more than anything else). My primary experience from that project was that there are some areas where fossil could be enhanced to allow easier integration with identity managers, which could ease user-management for very large teams. The biggest problem I have encountered with fossil is with regards to scalability. Anyone who has tried to use the NetBSD fossil repository knows it's a pretty painful experience. With that said, I came to fossil from bazaar which I abandoned because it had scalability issues (which were even worse), so it's not an exclusive fossil-problem. (git isn't affected by this though, but it's noteworthy that the NetBSD project on github is (was?) imported from the fossil NetBSD repository). -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
