> > On Apr 30, 2016, at 10:56 PM, Barry Arthur <barry.art...@gmail.com> wrote: > >> 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. >>
Sorry I didn’t read this carefully the first time. Yes that is what i’m suggesting, I want to use the feature branch for both isolated development as well as code review prior to committing to the trunk. Just trying to iron out exactly the sequencing of merge and update I need to do to create a smooth workflow for this. I think I have it resolved now that I understand better the relationship and difference between update, merge and checkout…my original question. The work flow would be this: (start with a clean checkout) (work on code) fossil commit —branch mybranch fossil merge trunk (resolve merge conflicts and test merged workspace) fossil commit (pass code review) fossil update trunk fossil commit Here is a DOT diagram if you’re interesting. digraph featurebranch { rankdir="LR"; node [shape=box]; trunk->DeveloperA[color=red]; DeveloperA->A2[weight=5,color=red]; trunk->2[style=dotted,weight=8]; A2->merge[weight=8,color=red]; 2->merge[style=dotted,color=red]; merge->3[color=red]; 2->3[weight=8]; trunk->developerB[style=dotted,color=blue]; developerB->2[style=dotted,color=blue]; }
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users