This page describes how to merge XC code with PostgreSQL. This is based on the merge with PostgreSQL 9.2.3. Future work may need improvement/correction.
- 1 1. Make the clone of Postrgres-XC repository
- 2 2. Move to the top directory
- 3 3. Add PostgreSQL repository
- 4 4. Get PostgreSQL code with fetch command
- 5 5. You will get messages as follows:
- 6 6. Switch master to PGXC's one with git-track command
- 7 7. Checkout PGXC master
- 8 8. Build new branch if needed
- 9 9. Find what to merge from PostgreSQL
- 10 10. Merge with the above commitId
- 11 11. You may need to set your user account
- 12 12. List of conflict files will be shown
- 13 13. You can find what files conflict with git status command
- 14 14. Edit them to resolve conflicts
- 15 15. Add the result to the repository
- 16 16. Repeat skip 13 to 15 for all the conflicting files
- 17 17. Build and run regression to check that the merge is finished.
- 18 18. Commit the merge
- 19 When to merge and how
1. Make the clone of Postrgres-XC repository
$ git clone <pgxc_git> pgxc
If you clone from the sourceforge, typical url of the repo is
where "your_account" is your account name to sourceforge.
2. Move to the top directory
Above example, move to "pgxc"
$ cd pgxc
3. Add PostgreSQL repository
$ git remote add postgres http://github.com/postgres/postgres
4. Get PostgreSQL code with fetch command
$ git fetch postgres
5. You will get messages as follows:
remote: Counting objects: 79387, done. remote: Compressing objects: 100% (21297/21297), done. remote: Total 67828 (delta 53455), reused 59396 (delta 46134) Receiving objects: 100% (67828/67828), 29.38 MiB | 23 KiB/s, done. Resolving deltas: 100% (53455/53455), completed with 3744 local objects. From http://github.com/postgres/postgres * [new branch] REL2_0B -> postgres/REL2_0B * [new branch] REL6_4 -> postgres/REL6_4 * [new branch] REL6_5_PATCHES -> postgres/REL6_5_PATCHES * [new branch] REL7_0_PATCHES -> postgres/REL7_0_PATCHES * [new branch] REL7_1_STABLE -> postgres/REL7_1_STABLE <snip> * [new tag] REL9_2_1 -> REL9_2_1 * [new tag] REL9_2_2 -> REL9_2_2 * [new tag] REL9_2_BETA3 -> REL9_2_BETA3 * [new tag] REL9_2_BETA4 -> REL9_2_BETA4 * [new tag] REL9_2_RC1 -> REL9_2_RC1
6. Switch master to PGXC's one with git-track command
You need to do so because now we have two masters for PGXC and PostgreSQL.
$ git branch --track master origin/master
7. Checkout PGXC master
$ git checkout master
8. Build new branch if needed
$ git branch REL1_1_STABLE
9. Find what to merge from PostgreSQL
Find commitID to merge using git log or git merge-base command.
To avoid to have huge amount of PostgreSQL commit messages to PGXC, we should use the "latest" commitID in a branch. If you need to skip several of the last commits, it's bettwe to hard-reset skipping ones.
The following example finds commitID for postgres/REL9_2_STABLE and postgres/master.
$ git merge-base postgres/REL9_2_STABLE postgres/master
If you merge with REL9_3 (in the future), the command will be
$ git merge-base postgres/REL9_3_STABLE postgres/master
10. Merge with the above commitId
$ git merge <CommitID>
11. You may need to set your user account
You may have the folloowing message.
*** Please tell me who you are. Run git config --global user.email "email@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: empty ident <firstname.lastname@example.org> not allowed
Then, you register yourself with git config command. --global option is not necessary here.
12. List of conflict files will be shown
$ git merge c299477229559d4ee7db68720d86d3fb391db761 Auto-merging GNUmakefile.in CONFLICT (content): Merge conflict in GNUmakefile.in Auto-merging configure CONFLICT (content): Merge conflict in configure Auto-merging configure.in CONFLICT (content): Merge conflict in configure.in Auto-merging contrib/Makefile Auto-merging contrib/dblink/dblink--1.1.sql Removing contrib/hstore/hstore--1.0.sql Auto-merging contrib/hstore/hstore_io.c Removing contrib/pg_stat_statements/pg_stat_statements--1.0.sql Auto-merging contrib/pg_stat_statements/pg_stat_statements.c CONFLICT (content): Merge conflict in contrib/pg_stat_statements/pg_stat_statements.c
13. You can find what files conflict with git status command
$ git status <snip> # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: GNUmakefile.in # both modified: configure # both modified: configure.in # both modified: contrib/pg_stat_statements/pg_stat_statements.c # both modified: contrib/pgbench/pgbench.c # both modified: contrib/sepgsql/hooks.c # both modified: src/backend/access/transam/Makefile # both modified: src/backend/access/transam/transam.c # both modified: src/backend/access/transam/xact.c # both modified: src/backend/access/transam/xlog.c # both modified: src/backend/catalog/dependency.c # both modified: src/backend/catalog/genbki.pl
14. Edit them to resolve conflicts
15. Add the result to the repository
The following operation will remove added files from unmerged paths
$ git add <file_name>
$ git add src/incldue/tcop/utility.h
16. Repeat skip 13 to 15 for all the conflicting files
17. Build and run regression to check that the merge is finished.
18. Commit the merge
$ git commit -a
This commit is only for local repository. You need to push it to the remote repository then.
When to merge and how
It is very important to decide where we should make new branch for a release and how to complete the merge process. In Version 1.0, merge was done after all the development was done. It took time and was a bit painful. In 1.1 development, the core team tried a kind of parallel approach, to merge with PostgreSQL 9.2.4 while XC development was being done. This brought many confusions, especially to fix regression test among others. As a result, core team is going to do the following way.
- Make release branch only after all the XC development is done. It is not a good idea to do development at master and fixing things on the release branch at the same time.
- When all the development to a release is done, cut a new release branch.
- Merge with target PostgreSQL branch. Commit it without resolving conflicts so that everything is visible in public.
- Resolve conflict. This can be done in public. Resolvers can issue patches for others' review.
- Then resolve regression test conflict, one by one. Some of them can be assigned to different developer to work in parallel.
[End of the page]