The distributed/shared repository doesn't just hold trunk... it holds all non-private branches too. So when your developers are ready for you to review their work, they commit it to their task branch and then you (remotely) checkout/update to that branch (preferably into a fresh directory) and test/inspect their code. When you're happy with it, they (or you) can then merge their branch into trunk.
Private branches are not the default type of branch, so your devs would have to go out of their way to get this wrong. I wonder if your team has previously been using git...? I mean, is that the reason why you want to create wrapper scripts instead of just letting your devs learn to use the much simpler (compared to git) fossil commands themselves? Instead of wondering in thought space about how all these scenarios might play out, you'd be much better off setting up a test repo and playing through them until you and your team are comfortable with the tools and your workflow. On 1 May 2016 at 12:40, Steve Schow <st...@bstage.com> wrote: > > On Apr 30, 2016, at 10:19 PM, Scott Robison <sc...@casaderobison.com> > wrote: > > > > > So, update moves your working copy to the specified (or default) version > specified. Merge brings changes from the specified version into your > working copy without moving your working copy. > > > > > I think this sounds like the key distinction.. > > _______________________________________________ > 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
