Skip to content

Instantly share code, notes, and snippets.

@phinze
Created October 14, 2009 15:30
Show Gist options
  • Save phinze/210162 to your computer and use it in GitHub Desktop.
Save phinze/210162 to your computer and use it in GitHub Desktop.
#######################
# 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!

Possible Solutions

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

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

  3. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment