On 5/12/2015 9:23 PM, Richard Hipp wrote: > 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. > > 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.
It seems reasonable to me to use (new?) scripting hooks to specify constraints to be validated by the client on commit and again by the server on push/pull. This way the developer is informed as soon as possible when there is a problem, even during disconnected operation, and the local repository is not put into a disallowed state. But if the commit constraints are somehow compromised (doesn't even have to be malicious, may simply be due to a policy change that hasn't sync'ed out yet), the nonconforming artifacts are still not permitted to propagate. Obviously the latter is a failsafe, not the first line of defense, and when invoked it means the developer now has to fix the local repository or face errors on every future sync. Though this isn't much different than a user not having push privileges yet making changes to the local repository anyway. > 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. How does the above relate to your thoughts? > (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.) This is not a bad assumption to make. If we can only have part of what I described above, I'd take the client-side on-commit constraints rather than the server-side on-push constraints. This covers everything but malice and unsynced policy changes, which all should be vanishingly rare in the kind of professional environment where any of this matters in the first place. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
