On Fri, Apr 22, 2016 at 8:33 PM, Steve Schow <st...@bstage.com> wrote: > > > 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. >
>From the command line interface, autosync can be set to pullonly. That way, updates from the "central" or "upstream" repository will automatically be pulled. Also, Fossil will be able to check if the user is about to commit against a parent commit that already has a child commit in the upstream repository (this reduces the chance of accidentally creating an unnamed branch (also called "forking", not to be confused with "forking a project")). However, manual pushes are still possible. Is is also possible to set a repository as "don't-push". This completely inhibits pushing to the upstream repository - not even a manual push. (Though, the user could turn this setting off.) > 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? > Fossil can push/pull to/from any other repo with the same project ID. FYI, "pull requests" are a Github feature, not a git feature. > 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? > fossil pull //host/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. At work, my team keeps autosync on. We do all our code changes in branches. Our workflow is: 1. An issue ticket is created, describing either a problem or a specification. 2. (wait until issue is reviewed and approved) 3. A branch is created for that issue. 4. Make code changes, perform tests, committing as appropriate. (see note #1) 5. When done and all tests passed, change issue state to "In_Review". 6. Review proposed code. a. If rejected, revert issue to either "InDev" or "OnHold". Go back to #4 b. If approved, set issue to "Integrating" 7. Merge final commit of issue branch to trunk and test. a. If tests pass, set issue to "Integrated" b. If tests fail, set issue to "InDev". Go back to #4 8. When a "validation release" is made, set integrated issues to "InValidation".
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
