[CityGen] Procedure for checking in code?

thomthom

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...

Chris Fullmer

Thats odd. That is how I would have expected the process to work.

Commit.
Sync - look for incoming
then merge
then commit
then push changes.

Did you then have to do another merge?

thomthom

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.

thomthom

But do we really need two commits?

Chris Fullmer

Ahh, I see. That is because we were working on the most recent version from the server. Because:

I uploaded the original.
You pulled a copy from the server (or maybe already had a copy?)
Then I added a note to jim, but there had been no changes on the server since I downloaded it, so there was nothing to merge.
The Jim pulled from the server and delete my note. But hid not have to merge because nothing had changed on the server from when he last pulled the code.
Then I pulled from the server and did my code changes. Then re-pushed to the server. I did not have to merge again because nothing had changed on the server since I last pulled changes.
Then Jim pulled changes, then re-uploaded and did not have to merge since nothing had changed.
Then you pushed your work, creating a new project head I think? I'm not really sure what that would be called. I didn't know we could push un-merged changes. But you had to merge since the version on the server had changed since when you had pulled it. So you had to merge your code with what was on the server.
Then you pulled all changes, merged and committed and pushed.

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?

Chris

tbd

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)

Chris Fullmer

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....

Chris

Jim

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?

Chris Fullmer

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?

Chris

thomthom

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.