On May 12, 2015, at 6:23 AM, Abilio Marques <abili...@gmail.com> wrote: > > 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.
All of the permissions you’re talking about are binary: complete permission for the specified action or no permission at all. There are no permissions that are based on the repo content being changed, only on the *kind* of action. There are no per-branch permissions because permission checking and repository DB updating are at very different levels in the Fossil implementation. “Fixing” this would require punching through abstraction layers. drh explained this. > There is also one permission for check-in. Now, permissions to check in is a > subset of protected branches. To test for check-in permission, Fossil currently only has to ask: 1. Who is doing the action? 2. Does this user have check-in permission? Fossil does not have to dig into the content of the change set to figure out which branches it would touch, then crawl the repo looking for branch locking tags. > 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. All of these things you describe are like the check-in case: they check a user’s requested action against the corresponding permission flag without regard to the content of the repository *or* the change set. > Protected branches (as a generic concept) is nothing more than that. Yes, and a flying car is “just” a car with wings and a jet motor. You’re speaking only of concepts. Implementation is an entirely different thing. This is the “But can’t you just…” syndrome. “Just” is such an easy word to use as wallpaper over a whole pile of implementation details. > 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. I think drh was reacting more to things like the naming convention restrictions, branch coloring rules, etc. when he invoked that design principle. Restricting these things with software amounts to Fossil telling its users how they must use Fossil, which is a global imposition of policy. You are correct that the ability to lock a particular branch could be useful, and that adding this feature does not cause Fossil to impose any particular policy on its users. The only question in my mind is whether doing so is worth all the effort it would take to do it. I currently believe that is that it is not worth the effort, because if you need privilege separation for subsets of the code, you can already do that in Fossil, today, with multiple repositories. Bonus: Fossil performs better with smaller repositories. That’s incentive enough to avoid putting everything into one massive repository. > 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. That only works if the “during” hook script has a list of locked branches, and then only you only want to lock branches by name only. I think the OP wants this flag to apply to specific artifact IDs and their children, so that branch X may have 20 checkins on it while it is a development branch, and *then* it gets locked by the 21st checkin. Presumably, you’d also then want the ability to *unlock* a branch 10 checkins later, in the same way that you can open and close branches today. Your proposal doesn’t cope with this very well; you’d have to keep updating the “during” script any time the locking rules had to change. I think what the OP wants would require crawling the whole length of the branch, remembering the value of the last lock tag you encountered along the way to decide whether to allow the checkin. > Adding a software that monitors over RSS, also a complication. How is it more difficult than writing TH1 code to achieve the same end? Or C code, if the changes end up in Fossil instead? Is it simply that drh and friends have to write it instead of you? > Having n+3 levels of repos (one for dev … one for golden) is a complication. I think you misunderstood my suggestion. The OP said that each of his clients has artifacts in the repository that can’t be shared with other sub-sections of the repository, for unspecified reasons. He also talked about a shared code base. That’s an N+1 situation. Yes, it is indeed a “complication,” but it is one imposed by the OP’s policy. Fossil already provides the mechanism that will let his company enforce that policy. It’s not that it’s a huge hardship anyway. I myself keep some cross-platform libraries in one Fossil repo, separate from the code that uses these libraries, which each live in their own repositories. When the library changes, I build and install it. Now the new library code is available to the programs that use it; they will use it when they get relinked. This can be nearly transparent from the developer’s perspective. Fossil lets you check out multiple repos side-by-side, or even nest them with “fossil open --nested”. Now you have a tree full of code from multiple repos, with checkins each going to their proper repo. (There is currently one minor difficulty with this, which I take up in a separate thread, “Allow checkins on another repository”.) > Having a separate repo for each developer... guess what, also a complication. Who suggested that? My N+1 model is not at all the same thing. It’s repo-per-client, not repo-per-dev. I would hope that each client repo is relatively small, and that most development occurs on the “+1” repo. > 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 Straw-man argument. > 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. You sound like the sort who believes that policy manuals prevent employee errors. Policy only provides a justification for punishment. It is *competence* that prevents errors, and you only acquire competence through practice. Let your devs make errors. Teach them the discipline they need to avoid making those same errors again. I’m all in favor of tools that buttress discipline, such as compilers that give good warnings. The thing about compiler warnings is that the default warning level can only warn about things that are objectively wrong in some way. You can’t expect a compiler to warn that you shouldn’t name the variable with a leading “k”, or that you shouldn’t be putting a new function into file foo.c. (These are direct equivalents in C to what the OP is asking for in Fossil.) These are policy matters, and thus a people problem, not a tech problem. > 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. Ugly dolls are expensive where you live? As for schedules, the whole point of the Adobe practice is to encourage devs not to break the build, because that throws a speed bump into every other dev’s workflow, which causes schedule slippage. Fighting through levels of bureaucracy to effect a change to a “locked” branch also adds delay to the schedule. Any time you have to coordinate the actions of 2+ people, you add a delay to your organization’s OODA loop, which slows the whole organization down. One of the major advantages of a VCS is that it decouples the actions of those working on the project, keeping the OODA loops tight and fast. It’s exactly the same problem that prevents these multicore computers we all have from running N times faster than the single core speed. The more locking and coordination you add to the system, the more you choke throughput. (Yes, I know that there are programs that take full advantage of multicore processors. My point is that these are comparatively rare, and that they are difficult to write and debug even in those those cases it is possible to achieve sufficient concurrency to take full advantage of the processor.) As to your country’s employment law issues, I think I will take those up with you off-list. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
