On 5/11/2015 4:17 PM, Warren Young wrote: > On May 11, 2015, at 10:48 AM, Andy Goth <andrew.m.g...@gmail.com> wrote: >> >> X group manages Y branch. > > Didn’t we all learn how to share in kindergarten? > > If it makes sense for multiple groups with disparate interests to all > be working on a single common code base, with each group on a > different branch, you can treat incorrect checkins through the same > means you would if someone in group Y started tying up a network > printer in department X with constant printouts.
We have many customers with different requirements and firm restrictions on what can be shared between them, though we share as much as we can so that we're not duplicating effort. That makes it important to have automated as well as procedural restrictions in place. > I’m saying you may have a people problem, rather than a technical > problem. This is a matter for management, not IT. I know it's important that everything be reviewed, but with the high volumes of development I've seen around here, stuff can and does slip through. One process I've seen is having designated code line managers whose job it is to integrate work pushed forward by developers. It would make sense to restrict commit access to the integration branches to those who are procedurally authorized. Otherwise, a busy code line manager with many projects might just miss the fact that a developer checked something in directly to an integration branch. >> - Restrict the naming convention of branches > > I think that’s more widely useful, but only to protect against typos > and such, not to solve a people problem. Once again, in a busy environment, it's good to enlist the aid of the computer to check that policy is being followed. And in this case, not only would this help with typos, but it would also be good to make sure someone doesn't make a branch with the same name as something reserved for code line management or other administrative use. >> - Restrict the naming convention of non-propagating tags > > This is less useful, since you can delete a tag and reapply it to > rename it. I'm sorry, but I am having a hard time seeing the point of your statement in the context of this discussion. If the naming convention of non-propagating tags is restricted, how does deleting and reapplying dodge the restriction? I have in mind reserving names indicating releases, resolutions to tickets, and so forth. Furthermore, it can make sense to only allow certain users to be able to create non-propagating tags indicating stuff like QA approval or release. In another email I gave a scenario in which a programmer sneaks in a spelling fix after QA sign-off for release. Even though the version description document can and should give the SHA-1 artifact ID of the official release check-in, if anybody can move tags around, it's not safe to trust the symbolic tags. Yes, it's possible to see the history on tag changes, but that only helps an administrator to undo the damage, not so much to alert the unwary that it even happened. Remember that Fossil repositories are supposed to last forever, and that means there's plenty of time for someone to commit a control artifact that moves the tag indicating which check-in corresponded to a release that was made a decade prior. I won't disagree that this is a people problem, but in a large project, stuff like this can go undetected for a long time. >> - Restrict control cards, maybe just bgcolor, maybe others > > Are you saying you want all branches created by someone in group X to > be a particular color, even when that would cause a visual conflict on > the timeline screen? The current random (?) method has a good chance > of avoiding this. No, I'm just saying that maybe an organization may wish to limit which users can apply which kinds of control cards. Otherwise anybody with general commit access can have fun recoloring all the branches or individual check-ins to suit his or her whim, wasting time and confusing everybody else. And keep in mind that this won't necessarily be spotted right away, if the control cards target ancient history not under active development. >> - Restrict editing of old commits > > Why? If they’re just correcting a typo or a think-o, you really don’t > want the old checkin comment. If they’re trying to rewrite important > historical details to fit an agenda incompatible with the > corporation’s needs, Fossil lets you dig the true history back up and > assign blame where it belongs. What if a legitimate correction was already performed? Fossil only shows the original and the final changes, not the intermediates, so it can be hard to search for all superseded control artifacts in order to restore the desired version. Basically I'm saying it should be possible to lock old stuff so it can only be amended further by administrators or code line managers who have authority over the branches in question. Don't get me wrong; I'm not asking for all this functionality to be added to Fossil itself. I'm only suggesting that its scripting system be flexible enough to allow an organization to institute these policies and others, so I'm giving a variety of examples drawn from things that I've seen around the office. > As for your original request to restrict trunk checkins, I think the > timeline RSS feed gives you everything you need already. The person > responsible for trunk monitors checkins to trunk and jumps on any > idiot who checks something bogus in. This builds institutional > awareness, which eventually solves the problem. > > http://fossil-server/timeline.rss?r=trunk This is a help, but requiring eternal vigilance over all branches, including those that haven't needed to be touched in years, is going to hurt Fossil's adoption in organizations like mine. Not saying I'm not using Fossil, only that I'm having to use it in a clandestine sort of way because we're supposed to be using ClearCase and Perforce. -- 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
