>
> 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
