<div dir="ltr"><div>To everyone that jumped in to help, thanks again. In the meanwhile it seems I have found a fix for this particular problem. I looked at all Launchpad bugs for fast-export and applied the patches/solutions found one by one. The set of changes that works for now is:</div>
<div><br></div><div><div>=== modified file 'exporter.py'</div><div>--- exporter.py<span class="" style="white-space:pre"> </span>2012-02-28 16:16:13 +0000</div><div>+++ exporter.py<span class="" style="white-space:pre"> </span>2014-03-04 20:10:38 +0000</div>
<div>@@ -365,14 +365,7 @@</div><div> self.print_cmd(commands.CheckpointCommand())</div><div> </div><div> def _get_name_email(self, user):</div><div>- if user.find('<') == -1:</div><div>- # If the email isn't inside <>, we need to use it as the name</div>
<div>- # in order for things to round-trip correctly.</div><div>- # (note: parseaddr('<a href="mailto:a@b.com">a@b.com</a>') => name:'', email: '<a href="mailto:a@b.com">a@b.com</a>')</div>
<div>- name = user</div><div>- email = ''</div><div>- else:</div><div>- name, email = parseaddr(user)</div><div>+ name, email = parseaddr(user)</div><div> return name.encode("utf-8"), email.encode("utf-8")</div>
<div> </div><div> def _get_commit_command(self, git_ref, mark, revobj, file_cmds):</div><div>@@ -529,7 +522,9 @@</div><div> </div><div> must_be_renamed = {}</div><div> old_to_new = {}</div><div>- deleted_paths = set([p for p, _, _ in deletes])</div>
<div>+# jal fix from launchpad</div><div>+# deleted_paths = set([p for p, _, _ in deletes])</div><div>+<span class="" style="white-space:pre"> </span>deleted_paths = set([p for (p, _, kind) in deletes if kind != 'directory' or not self.plain_format])</div>
<div> for (oldpath, newpath, id_, kind,</div><div> text_modified, meta_modified) in renames:</div><div> emit = kind != 'directory' or not self.plain_format</div><div>@@ -572,6 +567,8 @@</div>
<div> new_child_path))</div><div> file_cmds.append(commands.FileRenameCommand(old_child_path.encode("utf-8"),</div><div> new_child_path.encode("utf-8")))</div>
<div>+ if new_child_path in deleted_paths:</div><div>+ deleted_paths.remove(new_child_path)</div><div> </div><div> # Record remaining deletes</div><div> for path, id_, kind in deletes:</div>
</div><div><div><br></div></div><div>Adding this allowed me to at least have a successful conversion of all 50 related branches to Git - at least at this moment..</div><div><br></div><div>I am seeing this whole thing as a warning though. When I started work on migrating to Git the idea was to keep bzr as long as possible, as it's clearly better in many ways, and why move away as long as it works, right? I planned to take this year to leisurely fix all our tools to support git too. But to me this shows there is a real risk; git moves and changes, this in turn has effects on how it handles imports which might cause bzr's export to break more and more. And what is exceedingly clear here is that no one is maintaining it at all. As seems to be the case with the other tools that were mentioned in here. So the real risk is not bzr: it is the risk of losing your repository or having to do substantial work on fast-export if you postpone migration. Which is sad news; I have to speed up moving to git. And boy, the more I use it the more I hate it 8-/ I think it's the first time I've seen an actively user-hostile user interface..</div>
<div><br></div><div>> This probably doesn't help you, but when I switched from svn to bzr, ....</div><div>Well, sharing pain does help ;-), and I fear that you are right. But I was under the impression that the whole fast-export toolset was quite well defined and supported, considering I'll not the only one that needs to migrate from bzr to something else 8-/.</div>
<div><br></div><div>Anyway, again thanks everyone for your help!</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 5:24 AM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Chris Hecker writes:<br>
><br>
> This probably doesn't help you, but when I switched from svn to bzr, I<br>
> had to write a bunch of filters and hack existing scripts and whatnot to<br>
> get everything to import, and my repo was relatively simple. I think<br>
> there's no robust tool for this because nobody does it often,<br>
<br>
</div>Come to think of it, Eric Raymond has been advertising a new (?) tool<br>
of his own called "reposurgeon". Like everything ESR does, it's the<br>
best ever and no improvement is possible. ;-) Author's well-known ego<br>
notwithstanding, I bet it's pretty good -- if you haven't tried it yet<br>
it's probably worth a shot.<br>
<br>
Caveat: untested (by me). :-)<br>
<br>
<br>
<br>
</blockquote></div><br></div>