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

Reply via email to