First let me state the purpose of gatekeeping is not because I don’t trust devs not to delete something. Its to keep the mainline containing at all times, only “approved" code. I am not even worried about perms and stuff or devs trying to skirt around it, everyone I work with is friends, this is just about making it very error-proof so that most of us won’t have to think so hard about the scm tools when introducing code, we can just think about the change, get approval and add it to the mainline in a systematic fashion that prevents user error, using wrapper scripts that enforce a methodical work flow with absolute minimal need for a dev to make any decisions in the process about how to do it, other then addressing merge conflicts when asked to.
the question about auto-sync is only an open ended question. There could be some work flows that may work with or without it as far as i can tell, but i’m just asking about what others might be doing.. with auto-sync…anyone who commits to a cloned repo is going to push their change into the server repo without code review. no bueno. The git approach you mention, let me ponder that.. where the gatekeeper will pull from the other repos.. that is essentially with auto-sync disabled…such that when they do a commit, their changes would not be pushed to the server repo. Then in git fashion they can do something similar to a pull request to the gatekeeper, who can review the code..and pull the code over from their end..but I’m not sure how they do that in fossil terms. In git you can push and pull from any repo to any other repo…like that…but….I didn’t get that we could do that with fossil? For sure it could be possible to keep auto-sync disabled, and then after code review have the dev push to the server. In a perfect world it would be better to block those somehow and only allow pulling form the server as you suggest, in git fashion, so that the gatekeeper has to be the one to actually do it. But how does one pull from the clone to the server repo? One disadvantage of the above suggestion is that the local repo the dev is using is not being kept on the server machine with backups, etc. In another solution with auto-sync left on, then a separate branch needs to be created so that the dev can commit their changes…the changes will get pushed to the server (but on a different branch). then the code review process can happen completely in the server repo and using a merge to bring the changes back into mainline there. On Apr 22, 2016, at 5:31 PM, Thomas Levine <_...@thomaslevine.com> wrote: > On 22 Apr 15:38, Steve Schow wrote: >> 3 - whether to use auto-sync or not. > > I think you are making things overly complicated in question 3. > If I understand properly, you want one trusted person to approve code > before it gets into trunk on the main repository. Here is a policy that > could accomplish that. > > Everyone works on separate repositories. When someone wants to > put something in the main repository, he or she contacts the person who > can write to the main repository, noting the branch, tag, or checkin. > When that person approves of a change, he or she pulls from the > appropriate repository and pushes to the main repository. The contact > could occur inside tickets in the main repository, if you like. > This is, in fact, the exact same workflow I would use with git. > > I don't see the connection to auto-sync. > > It is quite difficult it is to delete information from a fossil > repository, so I don't think you have to trust your developers as much > as you would with a git repository. Because of that, you might be able > to come up with a less cumbersome workflow, such as the one that Richard > alluded to. > > > > I'm not very good at fossil yet either, so I don't have thoughts on > the other questions. > _______________________________________________ > 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
