On May 12, 2015, at 5:51 PM, Scott Robison <sc...@casaderobison.com> wrote: > > the difficult part comes in the sync, since they only deal with artifacts. > Once someone clones the repo, they have full access to that copy to do with > as they please.
I’m not so sure about that. I think all that is required is for the access tags to be checked on both check-in and on sync. In the normal case, the tag that marks a branch as “locked” will be cloned down to the developer repos, so the local Fossil will have all the info it needs to refuse a check-in to the wrong branch. That does only protect against non-malicious checkins, but if the master repo also checks the access tags on sync, it will refuse to accept a black hat’s malicious change set. Problem solved. Obviously this means the sync protocol has to become aware of these tags and such. Nontrivial, I know, but not impossible. It would mean that sync has to involve something more like what “timeline” does. It would probably add quite a bit of processing overhead to the sync protocol. The only way I can see that you can get into trouble accidentally is if an admin locks a branch on the master repo while you are running with autosync disabled or blocked, such as because you are currently without Internet access. You could end up making several changes to a locked branch, then only get the sync error later. That should be an edge case, though. Good practice would be to avoid locking branches that are likely to be under active development. If you do get into such a state, you could imagine extending the bundle mechanism to allow one to extract the changes from the intended branch and re-graft them somewhere else in the tree. The “bundle export --standalone” command may help here. Anyway, I’m still against this feature in principle, because I think it tries to invent new mechanisms where they aren’t strictly needed. But, it’s a fun design problem. :) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
