On Mon, May 11, 2015 at 2:17 PM, Warren Young <w...@etr-usa.com> 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. > > I’m saying you may have a people problem, rather than a technical > problem. This is a matter for management, not IT. > Different strokes for different folks I guess. Does your team use Unix file permissions to prevent people from viewing files they have no right to be looking at? In my experience there are many times where a few judiciously applied controls make *everyone* happier. The free-for-all model can result in a cognitive burden if I have to expend mental energy worrying that I'm committing to the wrong branch. A system that prevents me from making a mistake can be an asset. The key of course is to not over do it. A system with multiple layers of control can kill productivity also. For many projects there is probably a sweet spot not at either end of the spectrum. > > > - 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. > > > - Restrict the naming convention of non-propagating tags > > This is less useful, since you can delete a tag and reapply it to rename > it. > > > - 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. > > > - 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. > > Again, this is a people problem, not a tech problem. > > 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 > > I read once that Adobe has a practice of requiring that the last person > who broke the CI build keep an ugly doll or something hanging on their > office door. A “scarlet letter” kind of thing. > > Devs learned to be *very careful* not to break the build, when everyone > walking past their office could see who screwed up last. Once everyone is > being careful, a careless slip could leave that doll hanging there for > weeks. > _______________________________________________ > 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
