I'm not an expert, but let me see if I can explain. Given the current state of your working copy, "update version" will merge the changes between your current working copy and the specified version. If you omit the version, it will use the most recent version on your current branch. If you specify a branch name as version, it will use the most recent version on that branch. If you specify a specific version, it will use that specific version.
Before you try running update, type "fossil status". It will tell you what your current checkout version is, and it's parent version. After you run update, your checkout version will be whatever you specified after "update" (or whatever it defaults to). If you run "fossil merge version", the "checkout" displayed by "fossil status" will remain unchanged, but all the changes from the specified version will be merged into your local working copy. If there were conflicts, they'll need to be resolved before you commit. And of course, just because a merge was "successful" (fossil didn't detect conflicts) does not mean that it was logically successful, which of course is why we need to test things before we commit them (but you knew that already). So "update" changes the concept of your current working directory. "Merge" does not. Update moves your working copy to whatever version you specify. Merge brings whatever version you specify into your local working copy without changing the version. Maybe something slightly visual would help: trunk:3 trunk:2 trunk:1->branch:1->branch:2 trunk:0 Let's say your current checkout is "branch:2" and you have a set of changes that you need to commit. You can run "fossil update" to make sure you have the most recent changes to branch (which you do, so no merge will be necessary). Then you "fossil commit" which will create "branch:3" like this: trunk:3 trunk:2 trunk:1->branch:1->branch:2->branch:3 trunk:0 At this point you have no uncommitted changes, so you want to merge branch back into trunk. Type "fossil update trunk". This will make your current checkout "trunk:3" and there can be no merge conflicts because all fossil does is "revert changes between trunk:1 and branch:3 then apply changes between trunk:1 and trunk:3". The reason there can be no merge conflicts in this case (you had no changes in your working copy after you committed branch:3) is that all potential conflicts were resolved previously when those other commits were made. Now your current checkout is "trunk:3" and you want to bring "branch:3" into it. Type "fossil merge branch". It will determine what needs to be done and bring your working copy to a state that includes "trunk:3" and the changes made between "trunk:1" and "branch:3". Some of the changes between trunk:1 and branch:3 could conflict with changes made between trunk:1 and trunk:3. If so, fossil will tell you and you know you need to deal with them. If not, great, though it's still good to review what has changed even if fossil didn't have any conflicts. Then build, then test, verify everything is working as it should, then "fossil commit" which will create "trunk:4": trunk:4 trunk:3 trunk:2 trunk:1->branch:1->branch:2->branch:3 trunk:0 Obviously, the actual version IDs will be sha1 hashes, so my "name:#" nomenclature is just a convenience for explaining. So, update moves your working copy to the specified (or default) version specified. Merge brings changes from the specified version into your working copy without moving your working copy. Does that help? On Sat, Apr 30, 2016 at 9:54 PM, Steve Schow <st...@bstage.com> wrote: > > On Apr 30, 2016, at 6:55 PM, Richard Hipp <d...@sqlite.org> wrote: > > > 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”. > > > wait now I’m confused. I assumed the “standard” way is fossil update > without any version specified, which looks for the newest leaf from where > we currently are checked out from. By non-standard, and I didn’t mean > anything judgmental by that, I just meant trying to run update with a > VERSION that isn’t even on the same branch…but I must not be understanding > the command still….since it sounds like you are saying its the normal > desirable thing to specify some other ancestor VERSION or version from > another branch?…I hope you’re saying that this is in order to merge another > branch into this one…within the repo. Yes? > > its not clear to me how I can create a merged branch somewhere that has > all of the tentative changes….in the repo…that can be reviewed > remotely….before commiting to the trunk. Sounds to me like its not > possible currently with fossil. > > What exactly is the difference between merge and update? > > _______________________________________________ > 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
