On Sat, Apr 30, 2016 at 6:47 PM, Steve Schow <st...@bstage.com> wrote:
> Merge conflicts are possible ANY time someone else edits a file and > commits it to the trunk while you have been working on a feature branch > rather then the trunk for a while. Lots of times, the software can merge > without conflicts, but sometimes no. And me personally I actually prefer > to visually inspect all merges, and manually approve them, but that’s just > me and my OCD. > > My workflow list may not be correct as I sit here thinking about it….and > one thing may have just become clear to me, please correct me if I’m wrong: > > merge merges a version into the checkout DB, without effecting the repo. > > update merges changes into a branch within the repo (and also the checkout > db). > > yes? > No. If you are on mybranch and you have uncommitted changes, and you run update trunk, your changes will not be committed to mybranch (effectively they will be reverted) and then they will be automatically applied to your working copy of trunk you just updated to. If you don't have any uncommitted changes, that can't happen. > > My two major goals here are this: > > 1 - I want devs to be able to work on a feature and commit their changes > to their repo without hitting the trunk right away. thus the feature > branch. no problem there. > > 2 - I want to code review exactly what they are going to commit to the > trunk right before they do it. The problem I see is that “merge" merges > into their checkout, not their repo, so there is no way to remotely code > review the final thing they are about to commit to the repo trunk. what > needs to happen is that I need to have the trunk merged into their feature > branch so that the final merged result will already be in the repo to be > reviewed remotely. > > So as I think about it…I don’t want to use merge.. perhaps this is a > matter of using the leaf of trunk to merge into their feature branch…if > that’s even possible. Then their feature branch will be the whole merged > enchilada that can be code reviewed remotely. Once approved, they have to > quickly use merge to merge the branch into their workspace, do a quick test > and then finally commit to repo trunk. > > so > > > fossil checkout trunk > > (work on code) > > fossil commit —branch mybranch > > (work on more code) > > fossil commit > > fossil update -n (i want to have the branch look like the trunk leaf > is merged into it, if that’s possible) > > (resolve merge conflicts when they rarely occur ;-) > > fossil update > (code review my branch) > switch context back to trunk for their checkout, not sure exact command > to use yet) > fossil merge mybranch > > (final feature test) > > fossil commit > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
