Note that you have to merge mybranch back to trunk, otherwise all the
changes made in mybranch will live happily over there forever. Once you
updated to trunk, you abandoned all committed work from the other branch.
On Sat, Apr 30, 2016 at 11:27 PM, Scott Robison <sc...@casaderobison.com>
wrote:
> I think that's close if I understand what you want. Maybe this gets you
> the rest of the way:
>
> (start with a clean checkout)
> (work on code)
> fossil commit —branch mybranch
> begin loop as many times as needed while working on mybranch
> fossil merge trunk
> (resolve merge conflicts and test merged workspace)
> fossil commit
> (pass code review) if needed
> end loop
> now you're ready to merge to trunk, so
> fossil update trunk
> MISSING STEP: fossil merge mybranch
> (resolve merge conflicts and test merged workspace because it is possible
> someone slipped another commit in after code review was passed)
> fossil commit
>
> On Sat, Apr 30, 2016 at 11:23 PM, Steve Schow <st...@bstage.com> wrote:
>
>>
>> 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
>>
>>
>
>
> --
> Scott Robison
>
>
--
Scott Robison
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
