bzr-svn svn-import and history across svn "renames"

[Chris Hecker]

> Rename inference would have severe performance consequences,
> primarily because bzr-svn supports more than just one-time imports.

Sure, it just seems like giving the user the option even if it's slower 
is better than no option that doesn't lose information.

> The ideal solution would be for Bazaar to support file copies, at
> which point bzr-svn can losslessly import all information present in
> Subversion.

But that's just at the roadmap/spec stage, right?  Or is it being worked on?

svn2bzr.py is almost working for me, it's just barfing on a directory 
that was renamed, then another directory added, then some files moved 
from the renamed directory to the new directory, all in the same 
changelist.  I'm trying to fix it now.

Chris


Jelmer Vernooij wrote:
> On Wed, 2010-06-30 at 02:20 -0700, Chris Hecker wrote:
>>> It's correct that this doesn't work. bzr-svn doesn't infer renames
>>> from copy+delete operations in Subversion.
>> Hmm, bummer, but thanks for the reply.  This seems like a sad thing, 
>> since bzr doesn't support copy, and svn doesn't support rename, and so 
>> the user just loses in this case.  It seems like maybe the easy case (cp 
>> plus rm in the same svn changelist) could be handled.
> Rename inference would have severe performance consequences, primarily
> because bzr-svn supports more than just one-time imports. The ideal
> solution would be for Bazaar to support file copies, at which point
> bzr-svn can losslessly import all information present in Subversion.
> 
> Cheers,
> 
> Jelmer
> 
>> Jelmer Vernooij wrote:
>>> Hi Chris,
>>>
>>> On Wed, 2010-06-30 at 00:14 -0700, Chris Hecker wrote:
>>>> I'm trying to switch from svn to bzr, and I've got my big old svn repo 
>>>> filtered out the way I want it.  If I check out the repo with svn, all 
>>>> the files are in the right place right, and all have the correct 
>>>> history.  The repo has no trunk/branches/tags structure, it's just a 
>>>> directory tree.
>>>>
>>>> If I bzr svn-import this repo, it seems to work fine, in that checking 
>>>> out the latest version works, but none of the files that were "renamed" 
>>>> inside the directories in svn at any point have history across the 
>>>> rename.  I understand that bzr doesn't support copies, and svn does 
>>>> renames with copy+delete, but the bzr-svn page seems to imply that 
>>>> history is kept across copies, or is this only true for branches from 
>>>> the trunk and it's special cased for the trunk/branches/tags format?
>>>>
>>>> I have a lot of file renames in my svn repo and I was hoping those would 
>>>> be converted to bzr renames.  Am I doing something wrong, or am I 
>>>> missing something?
>>>>
>>>> Example:
>>>>
>>>> Say there's a file /a.cpp, and I svn mv'd it to /code/a.cpp at r23, and 
>>>> then worked on it some more.  When I import to bzr, /code/a.cpp is 
>>>> there, and the history is there back to what was r23, but it doesn't 
>>>> have any idea about the relationship with /a.cpp.  svn log code/a.cpp 
>>>> follows the history across the copy, of course.
>>>>
>>>> Is there any way to get the svn renames to be recognized by bzr?  Should 
>>>> this be working and I've screwed something up with my svn dump 
>>>> filtering?  The fact that svn works properly on this repo seems to 
>>>> indicate it's okay.
>>> It's correct that this doesn't work. bzr-svn doesn't infer renames from
>>> copy+delete operations in Subversion. It is able to push renames that
>>> were made in Bazaar itself into Subversion and get those renames out
>>> again but does this by putting extra metadata there. 
>>>
>>> Copies work for all branch roots, not just trunk. It doesn't work for
>>> files.
>>>
>>> fastexport/fastimport is an alternative to converting your repository to
>>> Bazaar from Subversion, I'm not sure whether or not that support proper
>>> rename inference.
>>>
>>> Cheers,
>>>
>>> Jelmer
>