On Sat, Apr 23, 2016 at 1:04 AM, Steve Schow <st...@bstage.com> wrote:
> > Nice work flow… > Thanks. It is simplified to highlight the key parts. > In the above workflow, here are my questions: > > 1 - step#4 is fine because dev is working on a branch. do you have any > mechanisms in place to prevent them from accidentally committing a file on > the trunk instead of the branch at this stage of the workflow? > No. We don't. Before Fossil, we were using a commercially available VCS that did force doing development on branches, then merging to trunk, so we were already used to doing that. > 2 - step #8 should have the final commit I guess, because #7 merge only > merges into the checkout workspace to do final integration test. > I guess I simplified a little too much. (Or included too much) Between 7 and 8, there is an implied "repeat until making a release". And after 8 is "repeat until project ends". Yes, technically, the merge puts its result into the workspace, then test before making the actual commit (then update the issue status.. Anyway, the input to 7 (and 6) is the final commit of a development branch. And since several team members are working on different branches, steps 6 and 7 are applied to each dev branch that is ready for review. Our work rules require that each of us take time each day to review pending code changes. Most days, our integration person will have a few changes to integrate, so not much time is required. If a problem comes up in integration, that merge will be discarded and the issue related to the change that failed integration will be marked "InDev". The person who worked on that change set will then be responsible for fixing the problem in consultation with the authors of the "conflicting" changes. > > Overall I like this workflow, but I would like to make sure they can’t > accidentally push stuff from one repo to the other that they may have > committed to their own own repo, perhaps from a different workspace or by > accident to the trunk instead of the feature branch. Since push and pull > always transfer the entire repo with all versions that are there…if they > updated their local repo’s trunk in any way whatsoever, perhaps totally > unrelated to the ticket…it could slip through the cracks and be pushed to > the central server repo without any code review or notice. > > What am I missing? How can that situation be caught or prevented? As I said in my previous message, users' local repos can use either "autosync=pullonly" or "don't-push", which will impede pushing changes to the upstream (or main) repo - or any other repo. But, as I said, users can change those settings. You would have to trust them to not do so with out a very compelling reason. If my team were to use either of those settings, we'd use "autosync=pullonly". We trust each other enough to not do manual pushes without a very compelling reason. And by using "autosync=pullonly", we reduce the risk of some one changing a setting then forgetting to put it back. Alternately,Fossil does have provisions for "hooks". Currently, the hook scripts have to be written in TH1 (which can have TCL expressions embedded in it.) I have never done this, so I don't know how it works.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
