Matt Welland wrote:
> The scenario I'd like to see supported is roughly as follows:
>
> Work on a release is done. The release manager closes the branch so no
> one can accidentally merge or commit to it.
>
> A bug fix is needed. The developer branches off the closed node and
> fixes the bug and runs QA.
>
> The release manager can examine the bug fix, assess the QA results and
> then open the closed branch, merge the fix and re-close.
>
> I think this is a useful release flow.
With only slight adjustments, that flow is supported by the tagging
scheme that I outlined and that is used to much success and fanfare by
the SQLite and Fossil folks, as far as I can tell.
It is also supported by doing what you described, and just having your
bugfix dev open the leaf before making their new branch.
I am starting to wonder whether your issue is primarily around the
simplicity (or coarse-grained-ness) of the user authorization primitives
in Fossil. For example, perhaps you wish that you could say "user A can
create check-ins but cannot open or close branches".
If so, then it is worth noting a few things about that:
(a) Adding your own permission primitive is probably not necessary.
If you trust user A to make check-ins, why don't you trust them
to open and close branches?
(b) If you are only worried about inadvertent check-ins then you can
always correct them after the fact. Keep in mind that
the branch on which a check-in was made is super easy to change
in Fossil. Also, your release manager will be policing these
things and will send nasty emails to developers who don't follow
the local rules.
(c) If you are worried about developers that are so confused that they
are doing this often, and your training has consistently failed,
and this is causing an overall productivity problem... then fossil
is not your primary problem.
(d) If, despite all that you, *really* want a new permission primitive,
it's probably not too hard to add yourself. And DRH's code is
pretty fun to hack against, as many here will attest to. :-)
--
Eric A. Rubin-Smith
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
