On 5/11/2015 9:10 AM, Richard Hipp wrote: > On 5/11/15, Abilio Marques <abili...@gmail.com> wrote: >> I recall seeing no way of detecting a "push" to a specific >> branch. All I saw were deltas and stuff like that. > > To change Fossil to have the ability to prevent pushes to certain > branches, we would have to add knowledge of branches and check-ins to > the push/pull logic. > > Note also that this goes against one of the founding principles of > Fossil: that the VCS should implement mechanism not policy. That is > to say, details of who should be able to check-in to which branches > and whatnot should not be enforced by the VCS. Project policies need > to be enforced by some other means.
Can TH1/Tcl be used to implement such policies? I wonder if it's possible to tie this to the push/pull logic but rather the commit and tagging logic, such that the prohibition happens as quickly as possible, and the developer isn't in for a surprise when the eventual sync takes place but fails. This leads to a host of questions. Having local access to a cloned repository gives unlimited control, so (unless all committers are trusted) the push/pull logic needs to double-check the rules. Also, there's more than one way to put a commit on a branch, so checks need to be performed against control artifacts as well as normal check-ins. Also I want to draw a comparison to closed branches. Can closed branches be refactored to be implemented in terms of this new facility, or can the closed branch feature itself be expanded to provide the foundation for limiting write access to branches? -- 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
