10 posts • Page 1 of 1
I pushed some updates to SG, but I think I did it differently from you guys.
When I see the changes, http://code.google.com/p/citygen/source/list , I see that the changes you guys did all in on the same branch. Mine ended up in a separate which I had to merge.
What I did was first Commit my changes. Then go to Sync and download the incoming changes. I tried to click Update to Tip, bt then it warned me I'd loose my own changes. So I did a Merge - then a new commit. Then finally Pushed the updates...
Thats odd. That is how I would have expected the process to work.
Sync - look for incoming
then push changes.
Did you then have to do another merge?
No, I didn't have to do another merge - just one. But I saw from the changes page that you and Jim hadn't done merges when pushing updates.
But do we really need two commits?
Ahh, I see. That is because we were working on the most recent version from the server. Because:
That's my guess at how it happened. And I think two commits are necessary? First one to commit your work so it knows what is what. Then you merge in the changes - thereby changing your files again. So you have commit that. Then push it back.
That is more or less guesswork, but I think it is mostly accurate. Anyone else care to join in on helping understand the mercurial workflow?
take a look at http://hgbook.red-bean.com/read/ , Chapter 5. "Dealing with tricky merges"
see also Chapter 6. "Collaborating with other people"
forking is also nice (clone the repository on your machine and develop) and then send only the changes to the author to review/merge in the initial repository. you can see more graphically at http://github.com/nevyn/spot/network (you can drag left/right on timeline)
SketchUp Ruby Consultant | Podium 1.x developer
So in Thom's case, is that a "fork" then that he uploaded? does that set us up so we can all double check the code or something before deciding to merge forks?
I'll try to read the links you gave later tonight when I get a chance....
So far, I have not been able to formulate a simple and safe workflow.
I started out by cloning the online repo into /citygen - this is always just a clone and I only do updates in this repo - no editing.
I then initialized a repo (hg init) in the Plugins folder, and pulled from /citygen.
I do my editing and testing in Plugins, then commit in Plugins. I go to /citygen and pull and update from Plugins. I may have to do a commit (almost sure of it), and then that is the point I would push from /citygen to the online repo.
I do not think there will be any merging to do in this workflow. If I were to create another repo for experimenting and wanted to pull in the experimental code, than a merge would be needed.
Maybe we could use clftester account, or my google code account for experimenting with hg?
I think that sounds mostly good. Until you commit your work, then push it to your clone repo, then pull from the server and have to merge changes. Then you need to test the merged changes, so you push the marge back into the testing /plugins repo and find that during the merge you messed it up royally, and now you have deleted all your recent work.
I guess at that point you could revert the changes made in your plugins repo? and then try the merge again?
When skimming through TBD's link to http://hgbook.red-bean.com/read/ it seemed that what I did was right. I had to merge because the files I had was based on an older version, not the latest.
10 posts • Page 1 of 1