intermediate branch history is not kept when copying branch

Bug #44312 reported by Jelmer Vernooij
4
Affects Status Importance Assigned to Milestone
svn2bzr
Confirmed
Medium
Unassigned

Bug Description

Received from Erik Bågfors by email:

I don't have a dump file, but I can show how to reproduce it. Lot's
of commands below

# Create a svn repo.
$ svnadmin create /tmp/svnrepo
$ svn checkout file:///tmp/svnrepo repocheckout
Checked out revision 0.

# Create a trunk and put some revisions in it
$ cd repocheckout/
$ mkdir trunk
$ svn add trunk/
A trunk

$ cd trunk/
$ cp /etc/hosts .
$ svn add hosts
A hosts

$ svn ci -m 'created trunk and added hosts'
Adding trunk
Adding trunk/hosts
Transmitting file data .
Committed revision 1.

$ echo hej >> hosts
$ svn ci -m 'rev 2'
Sending trunk/hosts
Transmitting file data .
Committed revision 2.

$ echo hej >> hosts
$ svn ci -m 'rev 3'
Sending trunk/hosts
Transmitting file data .
Committed revision 3.

$ echo hej >> hosts
$ svn ci -m 'rev 4'
Sending trunk/hosts
Transmitting file data .
Committed revision 4.

# Create a branch

$ cd ..
$ mkdir branches

$ svn add branches
A branches
$ svn ci -m 'added branches'
Adding branches

Committed revision 5.
$ svn cp trunk/ branches/foobranch
A branches/foobranch

$ svn ci -m 'added branch foobranch'
Adding branches/foobranch
Adding branches/foobranch/hosts

Committed revision 6.

# Create a dump file

$ svnadmin dump /tmp/svnrepo > svnrepo.dump
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
* Dumped revision 3.
* Dumped revision 4.
* Dumped revision 5.
* Dumped revision 6.

# Run svn2bzr.py

$ ~/usr/src/svn2bzr/svn2bzr.py --scheme=trunk svnrepo.dump svnrepoconv
Revision 0 read
Revision 1 read
Revision 2 read
Revision 3 read
Revision 4 read
Revision 5 read
Revision 6 read
Nothing changed in revision 0
/home/bagfors/usr/src/svn2bzr/svn2bzr.py:531: DeprecationWarning:
bzrlib.branch.initialize was deprecated in version 0.8.
  branch = Branch.initialize(branch_path)
/home/bagfors/usr/src/svn2bzr/svn2bzr.py:90: DeprecationWarning:
bzrlib.branch.BzrBranch5.working_tree was deprecated in version 0.8.
  branch.__wt = branch.working_tree()
Committing revision 1
Committing revision 2
Committing revision 3
Committing revision 4
Nothing changed in revision 5
Committing revision 6

$ cd svnrepoconv/

$ ls
branches/ trunk/

$ cd trunk/
$ bzr revno
4

$ cd ../branches/foobranch/
$ bzr revno
2

Basically, trunk has more revisions than foobranch, eventhough
foobranch is created from trunk and should hold all it's revisions

Jelmer Vernooij (jelmer)
description: updated
Jelmer Vernooij (jelmer)
Changed in svn2bzr:
assignee: nobody → jelmer
Revision history for this message
Erik Bågfors (zindar) wrote :

Any news on this Jelmer?

/Erik

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

The problem here is the fact that Subversion reports branches/foobranch as being based on trunk:1 (not 5!) and a separate copy of trunk/foo:5 to branches/foobranch/foo.

This means svn2bzr will create branches/foobranch based on an old trunk and then copy over trunk/foo manually. svn2bzr will need to search for the latest revision that has both trunk:1 and trunk/foo:5 and copy from that revision instead. This, however, is somewhat complicated.

Revision history for this message
Erik Bågfors (zindar) wrote : patch

This patch solves the problem for me.

It looks through all files that are in a revision, and takes the max revno. However, I do not know if this will work if you have a commit that spawns multiple branches.

The code might be ugly....

/Erik

Jelmer Vernooij (jelmer)
Changed in svn2bzr:
status: Unconfirmed → Confirmed
Revision history for this message
Jelmer Vernooij (jelmer) wrote :

Marking this is unconfirmed as I'm not sure it appears in just my branch, not sure if it's a problem in the official one as well.

Changed in svn2bzr:
assignee: jelmer → nobody
status: Confirmed → Unconfirmed
Changed in svn2bzr:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.