Bug 3288 - convert ignores branchmap for trunk
Summary: convert ignores branchmap for trunk
Status: RESOLVED ARCHIVED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: convert (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-27 05:26 UTC by A. Budden
Modified: 2014-07-31 13:22 UTC (History)
3 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description A. Budden 2012-02-27 05:26 UTC
When converting a Bazaar repository, it is likely that the user will want to
map trunk to default.  However, this is not guaranteed to be the case and it
should be possible to override this behaviour with a branch map.  If a
branch map specifies a new branch name for 'trunk', this is currently
ignored by convert:

# Make a repository for testing
$ bzr init-repo --no-trees tb
Shared repository (format: 2a)
Location:
  shared repository: tb
$ bzr init tb/trunk
Created a repository branch (format: 2a)
Using shared repository: /home/al/test/tb/
$ bzr co tb/trunk wd
$ cd wd
$ echo "abc" > abc
$ bzr add abc
adding abc
$ bzr ci -m "Commit to trunk"
Committing to: /home/al/test/tb/trunk
added abc
Committed revision 1.
$ bzr switch -b development
Tree is up to date at revision 1.
Switched to branch /home/al/test/tb/development
$ echo "def" >> abc
$ bzr ci -m "Commit to development"
Committing to: /home/al/test/tb/development
modified abc
Committed revision 2.
$ cd ..



# Convert without a branch map to check
$ hg convert tb tm_normal
initializing destination tm_normal repository
scanning source...
sorting...
converting...
1 Commit to trunk
0 Commit to default
$ cd tm_normal
$ hg log --template "{rev}:{desc}:{branch}\n"
1:Commit to development:development
0:Commit to trunk:default
# This is correct as we haven't used a branchmap
$ cd ..



# Now convert with trunk mapped to 'release' and
# development mapped to 'default'
$ echo -ne "trunk release\ndevelopment default\n" > bm
$ hg convert --branchmap bm tb tm_branchmap
initializing destination tm_branchmap repository
scanning source...
sorting...
converting...
1 Commit to trunk
0 Commit to default
$ cd tm_branchmap
$ hg log --template "{rev}:{desc}:{branch}\n"
1:Commit to development:default
0:Commit to trunk:default

# Should be:
1:Commit to development:default
0:Commit to trunk:release
Comment 1 Patrick Mézard 2012-02-27 12:07 UTC
The reason is "trunk" to "default" rewriting occurs in bzr source, *before*
applying the branchmap. I did this when adding support to bzr branches to
avoid breaking the previous behaviour with single branches, using "default".
The subversion source also works that way.

But I agree all this is a little kludgy/historical depending on your point
of view, and if a branchmap is used it would be clearer to disable this
initial rewriting (that is, consider this rewriting as a default branchmap).
Comment 2 A. Budden 2012-02-27 12:16 UTC
Sounds like a sensible approach.  Is this difficult to implement?

From my point of view it's not a massive problem: I'm gradually updating a
script that converts lots of repositories in one go and it generates a
branchmap for everything, so I can just comment out the lines:

if branch == 'trunk':
    branch = 'default'

in bzr.py.

I just thought it was worth reporting as I could imagine it confusing people
when converting repositories (or worse: they could not notice until too late).
Comment 3 Patrick Mézard 2012-02-28 09:13 UTC
No, it is not hard to implement:
- Add a getdefaultbranchmap() to sources
- Implement that for svn and bzr
- Use it when --branchmap is not set
- Document how branch names are derived, for every source, in hg help convert.

One little problem is it breaks the existing behaviour for people remapping
trunk branches from subversion. I am not sure this is a big deal given the
new version would be more correct and less prone to namespace collisions.

But I will not implemented soon, so in your case just hack bzr.py for now
(or submit the fix :-) !).
Comment 4 Bugzilla 2012-05-12 09:28 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:28 EDT  ---

This bug was previously known as _bug_ 3287 at http://mercurial.selenic.com/bts/issue3287
Comment 5 Matt Mackall 2014-07-25 17:22 UTC
Bulk close: no activity for >2 years -> WONTFIX
Comment 6 Matt Mackall 2014-07-31 13:22 UTC
Bulk change recent WONTFIX -> new, more descriptive ARCHIVED state (sorry for the spam)