D. Richard Hipp wrote: > I initially set out to design Fossil so that anonymous users on the > open internet could commit and the permissions and signing system > would be sufficient to keep out malicious content. But I quickly > found that such a system is difficult to both implement and use. So I > backed up to the traditional model of only giving check-in privileges > to people you trust.
Is it possible to have some kind of more granular permissions, even on just an advisory basis? For example, setting a "users" tag on a branch such that only users listed in the tag could checkin changes to that branch. People could still edit the tag or push their changes, but it could give a suggestion of roles and prevent some dumb mistakes. -J > Of course in a DVCS, anybody who can clone can also do local check-ins > to their private copy of the repository - there is nothing you can do > to stop them. But you can stop them from "pushing" those changes back > into official servers. That is what we do at Fossil and SQLite. Any > anonymous user can clone the repositories and start checking in > whatever they want to their local copies. But they can't "push" the > results back to official Fossil or SQLite servers. > > Messes are avoided by simply not giving push privileges to anyone who > is likely to create a mess. Select your developers carefully, but > then trust them to do the right thing. In the (rare) circumstance > where a developer goes bad on you, there is alway "shunning" to clean > up the mess. Note that each SQLite server tracks the IP address from > which it received each artifact via push. This feature is there to > make it easier to track down and shun all artifacts from a single > rogue developer. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
