On Apr 30, 2016, at 6:55 PM, Richard Hipp <d...@sqlite.org> wrote: > > 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 my branch”.
Yes I understand checkout will stomp over whatever is in my workspace rather then merging in the code. Part of what I am wanting to do is prevent contributors from misusing commands at the wrong time. I’m asking some of the questions just to have absolute clarity of what everything does. By creating wrapper scripts that guide them through a process, this kind of accidental stomping over a workspace can be avoided. I can step in for special circumstances to use direct fossil commands if and when its needed, which hopefully won’t be that often. So for example, I see checkout as being relevant only at the start of a feature, with no current files added and waiting to be committed in the checkout. But my understanding was that checkout will fail anyway if we have any uncommitted files, as long as we don’t try to force it with options. Update on the other hand will change which version the checkout is corresponding too, but with merged in stuff that i need to thnk about some more to make sure it will always be the behavior I want when switching between the base branch (i.e., normally the trunk, but not always), and the feature branch where isolated work is being done. > > 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. I’m not confused about that. Its the merging behavior I’m trying to get an absolute understanding of. My only question about checkout at this point is whether it does an implicit pull. My question about update and merge is about more specifically what is the difference between them and is there any way possible to merge two branches together in the repo? I think no. > > The "fossil merge" command then pulls the changes on some other point > of the graph into your local workspace. > >> Isn’t that what update does? >> > > Here is one of countless actual examples of the above workflow: > https://www.sqlite.org/src/timeline?b=4cbd5024&n=16&y=ci Will definitely check this out in the morning. Brain fried at the moment…thanks though, you always seem to dig great examples out of your sqllite history! The main thing I’m trying to figure out, as mentioned in the other email to Scott, is..how to be able to isolate developer activity to a branch which can be code reviewed remotely, ideally with a review of exactly what it is they are going to commit to trunk shortly….ie…the final merged code, just prior to being committed to the trunk. If I am understanding correctly, all merging in fossil happens into the checked out workspace. you can merge in from any other version in the repo, and it will attempt to retain the changes you’ve made in your workspace while merging them with whatever other version of of the repo you specify. In the case of the update command it also changes the checkout’s notion of which checkin it corresponds to. But how to get this merged together code into the repo prior to committing to the trunk, is the part I’m not sure how to do exactly the right way. It sounds like what actually needs to happen is, just prior to code review: while the checkout points to the leaf of mybranch, merge the leaf of trunk into mybranch and keep the checkout corresponding to the leaf of mybranch. so in the above sentence, after I have some commit —mybranch, and a few more commits…the checkout is corresponding to the leaf of mybranch. I want to stay on mybranch while merging in the leaf of trunk. So should I use "fossil merge trunk", to bring all the latest trunk change into mybranch in the workspace? followed by a commit to push all that merged stuff into to mybranch in the repo where it can be code reviewed? Once its code reviewed there, then finally do fossil update trunk, to bring it back to the trunk of my workspace, and finally commit again to finally commit all of the merged changes to the trunk? So i get the following workflow fossil open or checkout to leaf of trunk (assuming no uncommitted changes yet) work on code fossil commit —branch mybranch (commits new changes on a branch in the repo fossil merge trunk (brings the workspace up to date with everything that has happened on trunk and branch) (test again) fossil commit (commits the merged changes to the repo on the branch) (pass code review) fossil update trunk (changes the checkout to correspond to trunk again, without losing any changes) fossil commit (finally commits all of the merged changes to the trunk) One downside in the above workflow is that creation of a merged code checkin on the leaf of the branch prior to integrating it, for the sake of doing remote code review, but I can’t think of any other way to truly do a remote code review. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
