remote-bzr status

Hi,

It's been a very long time now since I talked about this on the list. The project (integration with Bazaar through a remote helper) is not dead, it's just stalled because of bugs in the chosen "backend".

The remote helper code was done in python (mostly based off of Sverre's remote-hg code) and relies on the "bzr-fastimport" tool. It can be found on my github repository:

http://github.com/lelutin/git-remote-bzr

First off, what was done for now?

- The remote helper is able to pull in changes in Git repos and to create tags.
- It is possible to push changes back _but_ only in some situations. The "bzr-fastimport" tool currently has bugs [1] that prevent it from doing what we want. I have included a patch in the remote helper repository to fix one issue on the fix that was proposed but the whole thing is not completely fixed.

[1]: https://bugs.launchpad.net/bzr-fastimport/+bug/347729

Why did I lag this much on this project?
Mostly because of lack of time. My $dayjob was far too demanding. But since I am now self-employed, I want to find some time to work on this and get it through.

I tried tinkering directly with "bzrlib" to make my own tool to import/export information from/to Bazaar, but it is a tremendous PITA (unstable API, bad documentation, exceptions thrown are not always easy to understand).

I have been working on the bzr-fastimport bugs but I didn't receive any feedback from maintainers. So I currently am wondering if I need to be pushing for this tool to be fixed or if I should reimplement it.

Any help and/or support would be appreciated. I'll keep posting status updates when I have new info or progress on the project.

Gabriel Filion

Hi,

| What may work:
| 
| - small repositories
| - cloning local branches
| - using differential import (although pushing is currently broken --
| see below)

Nice.

| What's being stopped by bugs in dependencies
| 
| - pushing (I've fixed a bug on Ian's branch -- see below -- but I've
| hit another one with using mark_files)

I notice that you are already maintaining a patches/ directory with fast-import patches that are needed. Seems like a sane approach.

Also good to hear. :)

What is the license on your code (if any)? Would you be interested in including it in contrib/ or core git?

hmm right, there's nothing about this in the repo yet..
I guess I'd put a GPLv2 license on it to be similar to git's license.

yes I would (after review from the community, and when the code reaches better functionality and testing.) It would mean greater visibility for the code, added functionality to git and the possibility for more maintainers to help ;)

My original plan was to try and make the helper work both ways, and then to incorporate it into git.git to build patches on top of master (since it's a new feature that should be working on the current master).

Gabriel Filion

Heya,

It would be great if you could make it work by adding a bzr directory to git_remote_helpers and a git-remote-bzr.py to the root directory!

Cheers,

Sverre Rabbelier

I have written a test file that uses test-lib.sh. It is named t5801-remote-bzr.sh. I don't know if this name is right so I can correct it. I simply took the next sequential number after t5800-remote-helpers.sh.

It is included in the repo mentioned earlier but it won't work in there..

I've created a clone of git.git [1] in which there's a 'remote-bzr' branch. I will be rebasing this branch on top of master and keeping it up to date with the other repo's content. (so most operations will be non-fastforward pushes)
The previous repository will contain the detailed history about work on the remote helper, while the git clone will contain a simple commit for the helper, plus relevant commits for integration in git.git. The test file can be used inside the git clone.

[1]: http://github.com/lelutin/git

Maintaining two repositories will add a little more work but it will make it easier for me to post a series on top of git for review and possible inclusion later.
Also, it should make it easier for interested people to test out the remote helper, and to run the test file.

So now, most of my work will be to try and fix bzr-fastimport. I tried to get in contact with current maintainers of the plugin via Bazaar's mailing list but was unsuccessful. I guess I should e-mail Jelmer Vernooij directly since he merged some code in not so long ago.

Gabriel Filion

Heya,

I also have a t8501-remote-hg.sh, I suppose whoever is done first gets 8501 eh? Easy enough to resolve when the issue arises.

That's how I've been working too (although I've thrown away the old history).

You could just drop the non-git repo and work just with the git.git fork (that's what I'm doing), whatever you're comfortable with though.

Yes, Jelmer is involved with the bzr fast-import/export stuff, definitely contact him if you haven't already.

Cheers,

Sverre Rabbelier

Heya,

Glad you found my code helpful :).

I see you are not using the 'export' functionality, which is good since it has a bug, but if you'd be interested in doing that, feel free to ping me in #git-devel on freenode or on gchat, and we can figure out what would be easiest.

I'd recommend working on 'bzr fast-import', forking it if necessary. Definitely preferable over creating a new tool from scratch.

Please keep up the good work, I'd love to be able to clone bzr repo's :).

Cheers,

Sverre Rabbelier