Re: From P4 to Git

[Alex Riesen <raa.lkml@gmail.com>]

On Mon, Aug 3, 2009 at 09:49, Sam Vilain<sam@vilain.net> wrote:
> Alex Riesen wrote:
>>> So it looks like you wouldn't _need_ to split source tree into separate
>>> smaller repositories for performance reasons.  Still it might be good
>>> idea to put separate (sub)projects into separate repositories.  But
>>> I guess you can do that even at later time (although it would be best
>>> to do this upfront).
>>>
>>
>> It looks like they use P4 branches. Which are NOT branches as Git
>> understands it (a line of history). The P4 "branches" are just directories
>> with some metadata regarding recording where the data in the directory
>> were before an act of "branching" (just a server-side recursive copy).
>>
>> In this case (and this must be, as there are no other branches in P4),
>> they'll have to split their repository.
>
> p4's branches are 'close enough'.  My tool travels through the history
> of the repository forwards, detects paths where new content was placed
> and calls those roots.  When branching is detected (recorded
> file-by-file in perforce), it puts the branch source as a new parent.
> When branches are 'integrated', it makes a fuzzy decision based on the
> number of outstanding merges it thinks are due, also based on a merge
> base calculation on the current view of the derived history.  It allows
> manual correction of this fuzzy information, and arbitrary grafting
> along the way.  Discrepancies between the fuzzy decision and the actual
> integration records are recorded in the commit log along with other
> metadata including the commit ID.

Sounds dangerous. And interesting...

Is it an import-once tool, or can the process be restarted? (because it looks
like the script needs a complicated setup).
Can it be used from a client machine? And more importantly:
can the branches be found from incomplete history,
restricted by path and changelist range? (because, in a corporate
setup, clients seldom have full access to all data).