On Wed, 27 May 2015 08:01:54 -0400 Martin Gagnon <[email protected]> wrote:
> On Wed, May 27, 2015 at 07:25:43AM -0400, Richard Hipp 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. > > ... > > > > > 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. > > > > I wonder if it would be a good idea to implement a new feature that > would be half way between per-branch push permission and emailing > bundles ? > > Example, we could add a command that would work exactly like a bundle, > (may be 'fossil bundle push' ?) but instead to generate a file locally > and email it, the user could push it to the remote and it could appear > like an attached bundle on the remote repository. That way, the > instructor could publish if he like the changes or purge it he doesn't. > > What do you think ? > I think this is very good idea! Now, the user needs to use second information channel (email) in order to make "pull request". In the same time, fossil already has working information channel - the client/server connection. It only needs some kind of "Inbox" where to store the received bundles and from where the owner of the repository to be able to review/merge (i.e. to make them part of the project history) or to reject/delete these bundles as not suitable. -- http://fresh.flatassembler.net http://asm32.info John Found <[email protected]> _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
