On Wed, 27 May 2015 13:25:43 +0200, Richard Hipp <[email protected]> wrote:
On 5/27/15, j. van den hoff <[email protected]> wrote:
he wants to ensure that
students can never mess up trunk, i.e. must technically not be able to
merge anything into trunk.
When the students have a copy of the repo on their local machine, they
can override any permissions that anybody sets up and do absolutely
anything they want with their local repository.
yes, I'm aware of this. I also am not advocating that functionality myself
but understand that it might be important for some. git people (if I
understand my colleague right) seem to put quite some emphasis on this
feature being crucial (is that correct??).
It would, in theory, be possible to deny a "push" to the student who
messed up trunk. But Fossil has decided not to go that route, as it
adds an inordinate amount of complication both to Fossil itself, and
to the user experience and workflow. For example, after the push is
denied, what does the student do with their repository then? They
have to figure out how to "undo" the trunk damage they inflicted?
Reclone and start over? How do they fix the problem? It gets to be a
big mess rather quickly.
keeping in mind that I personally *don't* want/need this: would it not be
possible to provide some `fossil setting' entry where read-only branches
are defined so that *local* checkins to that branch would be? this would
of course not prevent a malign or stubborn student to unset this entry and
go ahead with messing up both repos but it would prevent any accidental,
unintentional checkin or merge to the 'wrong' branch (and document it in
the fossil settings display). together with what you called 'push deny"
(which would really protect trunk at least on the server) this would then
work to keep both repos consistent, no?
could such a "voluntary restriction of local permissions on a per-branch
basis" make sense?
Fossil's approach to this is to implement mechanism, not policy.
People with "push" permissions can do pretty much anything they want
with the repository. But they cannot hide what they have done. They
cannot "cover their tracks". Fossil provides capabilities that make
it trival for the instructor to see that a student has pushed to
trunk, and to easily back out any changes to trunk. So if the
instructor will merely glance at the timeline from time to time, he
can clearly see that a policy violation has occurred, and a few simple
commands will fix the damage done - either by "fossil merge --backout
BADCOMMIT" or if the rogue commit is the last one on the trunk, he can
move it to another branch. Then he can deal with the student
adminstratively (ex: lower his project score).
personally, I agree and would proceed along these lines. but there are
sure users with a different view who insist on a mechanism to prevent the
bad checkins/merges in the first place.
The other approach would be to deny "push" privileges to the students
and force them to email in "bundles" that contain their changes, to be
added back to the trunk administratively by the instructor. That's a
lot more work on the instructor's part, but it does guarantee that
nothing he does not want gets into the trunk.
"a lot more work" would make this unattractive, of course.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
