On 5/12/15, Ron W <ronw.m...@gmail.com> wrote: > On the other hand, if [you] require such strict controls, > a DVCS, whether Fossil, Git or other, is likely not the tool you need.
Thanks, Ron. I was going to make this point earlier myself... In distributed VCS like Fossil or Git or Hg, the developer has direct access to a copy of the repository. That means they can change their local copy any way they want. Even if the tool does not provide the capability, a determined developer with a binary editor can still get the job done. So the only way for the central repo to enforce strict controls is to carefully analyze content it receives via "push" and reject non-conforming content. This is difficult to implement and maintain. It also leads to a situation where the content in the developers repo does not exactly match the central copy because some of the content was rejected. And it seems like inconsistencies between developer copies and official copies is something that you should be zealous to avoid. I recognize that some people want more control. But the right way to do that, I think, is to create a centralized VCS. A distributed VCS is not really the right platform for implementing a centralized policy. That said, I've been toying with ideas of a hybrid centralized/distributed VCS that tries to offer the best of both worlds - disconnected operation for availability but also close coupling to the central repo with the opportunity to enforce policy. Some of these ideas I've previously shared with my "Fossil 2.0" post. But all this is just speculation at the moment. Any implementation is a long ways off. For the short-term, if you have suggestions for preventing accidents and those suggestions are reasonable to implement, then we will certainly look into that. But do bear in mind that Fossil was never designed to implement rigid controls. I purposefully followed design rules like this: (1) Assume that developers (people with push privilege) are not malicious and will usually follow the rules. (Such assumptions are *not* made about users with less privilege, such as random passers-by on the internet, obviously.) (2) Provide lots of visibility into the state of the repository (many of reports and graphs and charts and tables) so that if one of your developers does break the rules, those rule violations will be easily visible. (In other words, promote situational awareness.) This is why, for example, all tag changes appear on the timeline. And this is why the "info" page for a check-in shows both its current comment/user/time and its original comment/user/time. And so forth. (3) Provide a detailed and immutable audit trail so that if violations of policy are detected, they can be tracked back to the perpetrator and dealt with administratively. Examples of this include the "rcvfrom" table in the database that records the time, login name, and IP address for all new content received. Again, we will certainly consider new features that are unintrusive and maintainable and that help prevent project errors. But adding dozens or hundreds of new details permission settings and doing low-level automated audits of content being pushed probably does not qualify as unintrusive and maintainable. So please continue to suggest new ideas, but also recognize that you might be trying to push Fossil to do things that it was never designed to do. Note that suggestions for improving the reporting and policy-violation-detection capabilities of Fossil will generally be better received than suggestions that try to get Fossil to actually enforce the policy. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
