On 4/30/16, Steve Schow <st...@bstage.com> wrote: > > So in some ways this seems that when update is called in this “non-standard” > way, its a bit more like a “merge”.
(1) This way isn't "non-standard". It is the usual use-case for "update". (2) Yes, "update" and "merge" are very similar Let your current check-out in your workspace be CKOUT. CKOUT includes uncommitted changes, so let the original check-in upon which CKOUT is based be called Y. "fossil update VERSION" first computes all the differences between Y and CKOUT. Then it checks out VERSION and applies those differences to the workspace. Let X be the most recent common ancestor between CKOUT and VERSION. Then "fossil merge VERSION" finds all the differences between X and VERSION and applies those differences to CKOUT. In both cases, a set of differences is computed and then applied. The only variable is what is the computed difference and what is it applied to. > > Just trying to make sure I understand all of the commands before before I > write some wrapper scripts, but the workflow I am hoping to promote here is > this: > > fossil checkout trunk Just to be clear: Your working checkout is now associated with "trunk". > (work on code) > fossil commit —branch mybranch Just to be clear: Your working checkout is now associated with "mybranch" because of the "branch" option on the previous. > (work on more code) > fossil commit Just to be clear: Your working checkout is still associated with "mybranch" because you have done nothing to change it. > (code review) > fossil update trunk -n Here you want "fossil update trunk" or "fossil checkout trunk" (They are the same thing here because you have not made any local changes since the last commit) followed by "fossil merge mybranch". Think of "fossil update" (or "fossil checkout") as similar to the "cd" command in the shell. It moves your working checkout to a different point on the graph. The difference is that "fossil update" carries any local, uncommitted changes with you whereas "fossil checkout" abandons any uncommitted changes. I never use "checkout" and suggest you do not either. Forget it exists. It is just confusing you. The "fossil merge" command then pulls the changes on some other point of the graph into your local workspace. > (resolve merge conflicts when they rarely occur ;-) > fossil update trunk Skip the "fossil update trunk" here. You are already on trunk. "fossil update trunk" would be a no-op. > (final feature test) > fossil commit > Here is one of countless actual examples of the above workflow: https://www.sqlite.org/src/timeline?b=4cbd5024&n=16&y=ci The initial "fossil checkout trunk" (or preferably: "fossil update trunk") happened sometime after 2016-04-27t15:24 when check-in 0065fe97 was the tip of trunk. Then Dan made local edits and did "fossil commit --branch permutations-fix" to start a new branch. Dan continued working on his branch while I continued making edits directly to trunk. Notice at 2016-04-28t14:59, Dan did "fossil merge trunk; fossil commit" in order to pull in all of my trunk updates into his branch. Then he made more changes. Finally at 29160-04-29t11:33, Dan did "fossil up trunk; fossil merge permutations-fix; ./configure; make test; fossil commit --integrate;" Note the extra --integrate option on the commit of the merge that causes the branch to be closed. It is very useful to close off branches when you are done with them so that views like https://www.sqlite.org/src/brlist can be used to see what is still active. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
