I kept my mind going around the initial response of Mr. Hipp, plus I kept reading the emails. And I don't want to continue a fight over this. But I must say some things, specially to get my mind clear on the idea of policy vs. mechanism.
If I go to any of my repositories in fossil, open Admin > Users, and I see a list of permissions. There is one for deleting wiki and tickets, one for append to tickets, one for check out versions, and so on. There is also one permission for check-in. Now, permissions to check in is a subset of protected branches. Actually, in a word with only protected branches, I can perfectly have the equivalent to permission to checkin, by making all the branches protected. At least I see it as a finer grained “permission to check in”, that denies or allows you to check in in specific special branches. Having said that, I wonder why the fuzz about the “Separation of mechanism and policy”. Perhaps I'm missing something when I read the theory, or I'm looking it from the wrong angle, but here I go anyway. Please feel free to correct me, as I want to learn. There is a way to work with private branches. I do most of my personal and freelance projects without using it. There are ways to restrict who can and cannot download a ZIP file. I've never used that, ever. Actually, never used half the permission flags in my entire life, besides the ones that come with the default categories. But there is a way, if I want, to avoid anyone from doing a check-out, or a check-in. So far I see mechanisms and you select whether to use them or not to fit your needs. Protected branches (as a generic concept) is nothing more than that. If you want to use them, fine, use them, if you don't, you don't protect anything and keep it cool... and if by including any mean to achieve that fossil is violating the “Separation of mechanism and policy”, then it was already violated when it included mechanisms to allow you to restrict who edits the wiki, or even sees the wiki, or work with tickets, or actually, the check-ins. Now, replying to the mail chain that followed my initial mail: Using the TH1 hooks seems a cool idea to implement it for those who need it, but sadly, the existing ones are only “post” commit or push. If there were “during” hooks, where you can detect the name of the branches being push into, and decide whether or not to continue with the push, that would be the way. Sadly only “post” hooks only allow you to email someone in case a “mistake” was made. About the other ideas. Adding the responsibility to watch over an RSS feed is a complication. Adding a software that monitors over RSS, also a complication. Having n+3 levels of repos (one for dev … one for golden) is a complication. Having a separate repo for each developer... guess what, also a complication. Initiate a tradition of making the guy wear donkey ears and stand in a corner of the office for 3 hours, really cute, but also a complication. Why? Because everything more complicated that the simpler thing is a complication. In the latter, it means 3 hours of work lost for an engineer because he is standing in the corner (yeah, it's a harsh non realistic measure). But in all the cases, it means time wasted deciding on how and then recovering from the mistake, more than if we didn't have to in the first place. For some companies, all of this could be acceptable, even cool (as the story with Adobe, I loved it), but for other companies with tighter budgets and schedules, it might not. A simplification: having a way (you can use it or not) to restrict commits in specific, special branches. No mistakes done in the first place, no fuzz about restoring the sanity, no special ears to be bought, no nothing. As a personal history, all of this seems easy in the first world, but for example, I live in a country where if you're a private company and you employ someone longer than 3 months, by law, you can't fire him/her, not even if he's stealing from you, not even if he burns down the building. Give him any kind of donkey ears and you could get closed by the government (no matter he agreed with it initially). Actually, even talking to him in a way he doesn't like could get the company closed. So, by the 17th time the employee has done a “mistake” like this, you can't do anything but blame yourself for hiring him. And if you have the option, disable the push to several branches, like trunk, for him. That also avoided me having to deal with Jenkins after the “mistake” was done. And by that story is that I found that feature in gitlab an useful one, and then I thought it could be useful for some other cases and some other people. On Tue, May 12, 2015 at 12:19 AM, bch <brad.har...@gmail.com> wrote: > > On May 11, 2015 8:40 AM, "Andy Goth" <andrew.m.g...@gmail.com> wrote: > > > > 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. > > I suspect this might really be the only safe(ish?) place to attempt the > job. > > > 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? > > I feel this might be best (as I feel about fork-notification) an "offline" > test applied to notify. Let social policy manage the sticky issues. > > > -- > > Andy Goth | <andrew.m.goth/at/gmail/dot/com> > > > > > > _______________________________________________ > > fossil-users mailing list > > fossil-users@lists.fossil-scm.org > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
