'bzr merge-into' doesn't support merging a project into an existing subdirectory

[Francois Deppierraz]

Currently 'bzr merge-into' doesn't support merging a projet into an existing directory.

Sample session, repo1 and repo2 were created previously.

+ cd repo2
+ bzr merge-into ../repo1 ./from-repo1
All changes applied successfully.
successful+ bzr commit -m 'merged repo1 in directory from-repo1'
Committing to: /tmp/tmp.fnWZzx8683/repo2/
added from-repo1
added from-repo1/file1
Committed revision 2.
+ bzr up
Tree is up to date at revision 2.
+ cd ..
+ cd repo1
+ echo NEW > file1
+ bzr commit -m 'Modified file1'
Committing to: /tmp/tmp.fnWZzx8683/repo1/
modified file1
Committed revision 2.
+ cd ..
+ cd repo2
+ bzr merge-into ../repo1 ./from-repo1
Conflict adding file from-repo1. Moved existing file to from-repo1.moved.
Path conflict: from-repo1.moved/file1 / from-repo1/file1
Text conflict in from-repo1/file1
3 conflicts encountered.

[HPO (hpo)]

This also prohibits re-merging a foreign branch (e.g. vendor branch) after that one is updated - if I understand it correctly.

[Jelmer Vernooij (jelmer)]

If upgrading to rich-root-pack is not a problem, you should be able to use "bzr join".

[HPO (hpo)]

bzr join --reference looks very promising! However, the documentation references old(?) formats unknown to me. I tried with 1.6.1-rich-root. Scenario:

a) existing branch with projectA
b) branch projectB within the A tree
c) bzr join --reference projectB
d) bzr status from projectA root

expected: projectB files should be "unchanged"
reality: projectB files are "unknown" - as well as projectB/.bzr

e) edit projectB/README (pre-existing)
f) bzr commit from projectA root

expected: include the README file in the changeset
reality: as projectB stays unknown, it is not included

Is there any doc available except the "help" text?

[Jelmer Vernooij (jelmer)]

please note --reference is still experimental (the rest of join is not). It also does something different than the merge-into plugin. You probably want "bzr join" without --reference.

[HPO (hpo)]

But join --reference will/would support the scenario I mentioned?

I wanted to use merge-into to support a vendor branch B (that gets regular updates by the vendor) included in my own projectA and applying local diffs to B. At certain times, I should be able to re-merge B into A, therefore applying the changes from the vendor but KEEPING my local diffs (manual conflict resolution, of course).

* merge-into only let's me merge the vendor branch once - no updates from the vendor ;( (Originally, I supposed, I could re-merge the branch and so apply the "new" changesets from the vendor)
* separated but nested trees lets me have vendor updates, but results in a patchwork of nested branches ;(
* "bzr join" equals merge-into (no more vendor updates after joining)
* "bzr join --reference" would keep the separated vendor branch (so updates worked) but include the diffs in my project branch?

Am I correct? If so, tell me how I can help/stress test ;)

[Jelmer Vernooij (jelmer)]

After "bzr join" you can keep updating the imported vendor branch code by running "bzr merge <vendor-branch-url>".

I'm not sure if 'bzr join' equals merge-into, afaik it's a bit more sophisticated at the cost requiring a newer format (I have no experience with merge-into, though).

if you use "bzr join --reference" you can't make changes to the vendor branch without these changes also going upstream automatically IIUC.

[John A Meinel (jameinel)]

They do the same thing.

After you've used "bzr merge-into ../other" 1 time, you can continue to use "bzr merge ../other" from then on to pull in any new changes, and it will find the existing files and update them.

[HPO (hpo)]

Aahhh! I'm seeing the light ;)

So, just to be clear (and document for others):

bzr join (w/o references):
Not only combines the branches, but also handles the relative paths, such that further merges from both the original and the joined branch work fine.

merge-into:
is superseded by "bzr branch & bzr join"?

[John A Meinel (jameinel)]

Basically. correct. merge-into isn't superseded yet, only because it doesn't require you to change your repository format for it to work.

[HPO (hpo)]

thanks a lot.

Concluding, the original reporter (and I) were wrong about the usage of merge-into: We thought, we had to use merge-into for each merge operation, while only the first merge-into is needed. Subsequent merges work with the "simple" merge command. "join" seems much more adequate as a name.

I suggest closing this bug as INVALID and documenting the correct process within merge-into and join.