Hi, Chris Cole wrote, On 09/09/2009 10:10 AM:
This is where things could get messy (and why I don't do it regularly) as it would be useful to get an insight into what changes to epxect before doing the update. It will help to verify that the merge was successful.
It could be that I'm not managing the changes optimally. Is there an ideal way to manage local changes within the context of upstream changes with mercurial?
If I may suggest one possible way - this is how we manage our local galaxy with some local changes and patches. First - learn to use mercurial. not just "hg update", but all the nitty gritty details. I recommend the following book (available freely online): http://hgbook.red-bean.com/read/ Keep several instances of galaxy on your server. One will be the 'pure' import of what ever the galaxy team releases. (it doesn't have to be the cutting edge revision, though). pull into it when ever the galaxy team releases new changes that interest you. Another instance (which pulls from the 'pure') can contain your local changes and patches. So each time you pull from the 'pure' version, mercurial will try to merge your local changes with the official changes. If the merge succeeds - good. if not - "hg resolve/diff/merge" are your friends. Once you've merged, test this instance (by running "sh run.sh"). If it works - good (by 'working' I mainly refer to your local changes/patches). If not - learn to use "hg rollback/backout/bisect' to pinpoint the problem. Also - get very comfortable with "hg tags" and "hg branches" - so you can very easily go back to a last-known-working revision. A third instance is your "production" server. it pulls from the second instance (with your local changes) only AFTER your merged and tested everything. This way - your production server is always working and stable. In general, learn to use: "hg inc" - will tell you what changes are ready to be pulled, WITHOUT pulling them (just print the list of changes). "hg inc --template '{rev}: {desc}\n' - will print the same list as above, but in one line per change. "hg fetch" - pull+merge+commit automatically (useful because your local changes will always create a new head when you pull - this shortcut command automatically merged the new head and commits, assuming the merge was successful. It requires some extension setup, see section "Simplifying the pull-merge-commit sequence" here: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html ). "hg update [REV]" - will allow you to switch revisions/branches/tags, and you can always be sure you can go back to a working version. To find changes that you've added (as opposed to the galaxy team), one way is to use templates+grep, as so: "hg log --template "{author}: {rev}: {desc}\n" | grep "[YOUR NAME AS AUTHOR]" Another would be to keep all your local changes under one named branch (not "default") and merged them. Mercurial also has a facility called "queues" or "mercurial queues (MQ)" which supposedly manages a set of patches on top of the local revision. It looks promising but I haven't yet learned how to use it. I'll be interested in hearing how other people manage their local repositories. -gordon.