bzr and perforce

[Josh Matthews]

I nabbed the bzr-p4 trunk, made sure I had p4 and p4d in my path, installed
P4Python (you should mention that in the docs, by the way) and the p4 api,
ran setup_evn.sh, and ran the selftests.  I got at least three failures, and
quite possibly more, but there was a metric crapload of information
streaming in front of me, so I have no idea what was actually happening.
I'm now stress-testing p4-fast-export against the project I'm working on,
which is upwards of 10 million LOC and probably ~10,000 files.  So far my
computer's become very unresponsive :)

On Sun, Nov 16, 2008 at 5:28 AM, Matt McClure <mlm at aya.yale.edu> wrote:

> Hi Josh,
>
> Thanks for posting to the list.
>
> On Sat, Nov 15, 2008 at 7:08 PM, Josh Matthews <josh at joshmatthews.net>
> wrote:
> > bzr fast-import takes the piped output of some frontend (in this case,
> git
> > fast-import, unless I'm mistaken).
>
> I think I misunderstood you the first time.  Yes, bzr fast-import
> takes the output from a front-end.  If you were migrating from Git to
> Bazaar, you could use the `git fast-*export*` front-end.  To my
> knowledge, Bazaar-Perforce is the first project to provide such a
> front-end for Perforce.  Git-p4 was doing most of the work, but it
> piped the stream directly to `git fast-import` instead of emitting it
> on stdout.
>
> > And I tried both git-p4, and git
> > fast-import directly, I believe (it was sometime in September, so I don't
> > remember that well).  Anyways, I'll investigate bzr-p4 some more at work
> > next week and see what the results are like.
> >
> > I've also been contemplating some stop-gap measures that would allow for
> > two-way communication with a perforce server.  Currently, my idea is to
> use
> > tailor to import the repo and keep it in sync.  Then I could write a bzr
> > command (p4submit) that would scan through all commits since the last
> > p4submit, find any that aren't marked as p4 changelists, and apply the
> diffs
> > to the original files in the local perforce workspace.  Then it could p4
> > submit the changed files with a commit message, and theoretically tailor
> > would then have no problems updating.
>
> The process you describe is very similar to what git-p4 does, and what
> I imagine the first two-way support in Bazaar-Perforce will do, though
> I don't intend to use Tailor.  The bzr2p4 tool in Bazaar-Perforce can
> submit changes to Perforce, as you describe.  It's missing a reliable
> way to determine which incremental changes it should submit.  I have
> only used it for complete one-way migrations from Bazaar to Perforce
> in the test suite.
>
> > Simply going through these thought excercises makes me appreciate how
> > wonderfully easy bzr-svn makes life.
>
> It's nice to have a proof point like bzr-svn that shows how much
> better the situation could be for Perforce.
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081117/c67a164d/attachment-0001.htm