On Apr 30, 2016, at 5:01 AM, Richard Hipp <d...@sqlite.org> wrote: > > Your current check-out and VERSION will have a common ancestor X. > Fossil finds all the differences between X and the current check-out, > then applies those differences to VERSION.
So in some ways this seems that when update is called in this “non-standard” way, its a bit more like a “merge”. In my mind, “update” brings the checked out workspace up to date with the rest of the repo if anyone has added stuff on the same branch its on. Its like a specific use case of merge, with an implicit pull added in. yes? what else would distinguish update from merge when its called that way? Normally update is doing a merge where the common ancestor is the checked-out version itself, and it merges in the leaf from there, as long as there isn’t already more then one leaf. That’s more likely to be an easy merge, and also the sensible one. That’s the normal default behavior without a VERSION argument. I guess what you’re saying is that in all other cases where its not a descendant, then fossil does the “merge” behavior of looking for the the nearest common ancestor and then merging from there, more like what the “merge” command does, but with an implicit pull also. Do I have that right? I’d post a dot graph here, but I’m not sure if the mail list allows us to attach images or not? 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 (work on code) fossil commit —branch mybranch (work on more code) fossil commit (code review) fossil update trunk -n (resolve merge conflicts when they rarely occur ;-) fossil update trunk (final feature test) fossil commit > > Fossil runs the 3-way merge automatically. That is what "fossil > update" does. There is no extra work to do on your part. I’m presuming what you mean is that during update, fossil attempts to automatically do a 3 way merge..and when there is a conflict it just bombs out and you can then undo it if you want. I already presumed that to be the case, and I presume that update -n would tell us info about the merge conflict? If not, then this is all a moot point I guess. What I wish to do is catch that situation proactively and automatically guide the user through the process of resolving the conflict by automatically providing the common ancestor and two versions to compare and if possible go ahead and feed that to a graphical diff tool that supports 3 way merge. Then they can merge it and save the result in their checkout workspace. Then a subsequent call to update should not fail from merge conflict. If update -n does not provide the information needed to do the 3 way manual merge, such as common ancestor and the two versions being compared…then this is a moot point unless there is some other way I would be able to script that information based on update -n or something? >> > I so rarely use "checkout" that I don't remember :-) Use the source, Luke! > > — Can you elaborate a bit on what you mean here by use the source luke? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
