Merge over the revisions with library changes into trunk and pull them into animal before committing BLUE's new feature.:
$ cd ../trunk.bound $ bzr merge -c1001 ../issues-blue/new-features +N blue/ +N blue/new-feature.code.OTHER M shared/library/library-Y/some_library_function.code Conflict adding files to blue. Created directory. Conflict because blue is not versioned, but has versioned children. Versioned directory. Contents conflict in blue/new-feature.code 3 conflicts encountered
ACK! Crazy conflicts and no merged commits.
Merge over just the paths with changes in the revisions with changes.:
$ cd ../trunk.bound $ bzr merge -c1001 ../issues-blue/new-features/shared/library-Y M shared/library/library-Y/some_library_function.code $ bzr ci -m "Changes from r1001 on blue/new-feature, add library call" Committed revision 2828.
No conflicts, but no merged commits, and sort of tedious.
We can extrapolate this where we do a task branch off trunk and pull in each set of changes and commit them separately with some sort of decent annotation, then merge the task branch back with trunk as one commit.
To conclude we merge trunk.bound -> blue.bound, and then finally merge in our new-feature branch into blue.bound.
- We somehow split out development of plugin-X and library-Y into completely separate branches and pull them in. I don't know how this would work out.
Created
October 14, 2009 15:30
-
-
Save phinze/210162 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
####################### | |
# Our Bazaar Problem | |
####################### | |
'trunk': production code | |
'project-*': big unlanded mainline development branch, tracks with trunk, will someday land in trunk | |
normal development: | |
trunk project-BLUE project-RED | |
| | |: | |
v v v | |
* * * | |
|\ |\ |\ | |
| * bugfix-foo | * feature-bar | * feature-baz | |
| | | | | | | |
| v | v | v | |
| * | * | * | |
|/ |/ |/ | |
* * * | |
| | | | |
: : : | |
usually this works, since 'project-BLUE' code goes in BLUE:: namespace and | |
therefore 'blue/' subdir, similarly with 'project-RED', however... | |
we have a continuing problem with development on shared libraries in certain | |
directories like: | |
trunk/vendor/plugins/plugin-X | |
trunk/shared/library/library-Y | |
example session: | |
$ bzr branch blue.bound issues-blue/feature-bar | |
$ cd issues-blue/feature-bar | |
Created new branch | |
# hack on blue/new-feature.code | |
$ bzr ci -m "New feature inital code" | |
A blue/new-feature.code | |
Committed revision 1000 | |
# hack on shared/library/library-Y | |
$ bzr ci -m "Adding option to some library function, and to calling reference in new-feature" | |
M shared/library/library-Y/some_library_function.code | |
M blue/new-feature.code | |
Committed revision 1001 | |
# need to tweak the library option | |
$ bzr ci -m "Renaming the new library option, and fixing the call" | |
M shared/library/library-Y/some_library_function.code | |
M blue/new-feature.code | |
Committed revision 1002 | |
# hack more on blue/new-feature.code | |
$ bzr ci -m "Finishing up new feature" | |
M blue/new-feature.code | |
Committed revision 1003 | |
# Now I need to get my feature into project-BLUE and the library changes over | |
# into trunk, and here I don't know what to do! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment