New user problems

[Bosco Rama]

John Arbash Meinel wrote:
> On 7/13/2012 2:21 AM, Bosco Rama wrote:
> 
>> I have been directed to migrate our existing Perforce setup to
>> bazaar.  We are trying to use a set of centralized repos with
>> decentralized devs.  We are trying for the 'decentralized with
>> shared mainline' workflow.
> 
> That is probably the best overall workflow. It gives a lot of
> flexibility for development, but also gives you a stable shared
> location to start new work from.

That's definitely what we are aiming for.

>> The specified tool (p4-fast-export) only seems to import the
>> revision history and not the actual files.  At least, nothing shows
>> up when I do a 'pull' from the created repo.  'git-p4' works but
>> that requires a trip through git with the associated cruft that
>> brings to the table.
> 
> It is certainly possible that there is a problem in the pipeline. I
> don't know p4-fast-export specifically. Is it tied to bzr, or is it
> generic? In theory, the git 'fast-export' stream should be valid to
> pipe into git or into 'bzr fastimport' directly.

Matt indicated that p4-fast-export, which used to be an included part
of bzr-fastimport, was an implementation/adaptation of an older git-p4
that was augmented to output a fast-export stream instead of directly
adding the extracted files & history into a git repo/branch/trunk/???.
I've looked at the current git-p4 and it (understandably) still has
the git bias with no ability to stream output.

>> I'm also trying to muddle through the whole conversion from multi-
>>  view mappings in a p4 client to the single tree approach that most
>>  of the DVCS's seem to use.  Any hints would be greatly
>> appreciated.
> 
> I don't know the specifics of 'multi-view mappings'. Is it multiple
> layouts of the same source?

Essentially.  Basically, you can map different areas of the p4 repo
into your workspace at any point in the hierarchy.  Very similar to
the *nix 'fstab' and mounts.  So if the repo has areas proj1, proj2,
external and common we can set up a p4 client definition that creates
a workspace like this:
      proj1         -> myproj/
      common/tools  -> myproj/tools
      external/app1 -> myproj/tools/app1

I'm so new to DVCS that I'm not even sure you can do anything like this
in things like bzr.  If I'm reading things right this would constitute
sub-branches.

(Don't get me started on overlay mappings. :-p )

> If that is true, I would tend to break up the conversion into multiple
> effective 'repositories' for each sub-view, and then combine them
> together later (as part of a build step).

I'm pretty certain we'll end up having to do that and possibly resolve
any internal path issues with relative symlinks,

> So each library gets its own history, rather than having 1 giant
> history of all libraries and all applications.

Yep.  Exactly what we're looking for.

>> And one final issue I'm running up against is the whole 'rcs
>> keywords' thing.  I pulled the bzr-keywords plugin, installed it
>> in my plugins directory with the proper name and when I try to run
>> either the selftest or even get help I get the following error:
> 
>> 'module' object has no attribute 'filter_stacks_registry'
> 
>> Maybe I'm missing a required package or plugin?  However, I've been
>> unable to find any hint of what that may be.

I'm still no further ahead on this one.  Anybody have any insights?

Bosco.