[p4] p4DTI in Perl ?

[Weintraub, David]

> The open-ness of Perforce makes lots of things possible and
traditionally they
> have drawn the line at a certain point and said stuff the other side
of the line
> *can* be scripted and looked after by others, and therefore
> *should* be (leaving them to focus on core product features). As to
where this line
> is drawn one we all of course have different opinions. It's a bit like
the Unix philosophy 
> of lots of little utilities that can be strung together with pipes etc
to achieve some
> remarkably sophisticated processing from simple building blocks.

I'm not complaining about the openness of Perforce, but when a task
becomes a common enough endeavor, you want to take it out of the realm
of third party scripting, and move it into a realm where it becomes a
fully supported feature in your core product. CVS to Perforce conversion
would fall into this realm. At the same time, I would not expect a to
see a built in StarTeam to Perforce conversion since StarTeam is a much
less common and very proprietary version control system.

Although merging two separate Perforce server instances is not an
everyday task, it is common enough and important enough that you would
want a robust utility to carry out this function. Companies reorganize
themselves everyday, and that includes reorganizing how they handle
their source control. Company "A" buys out Company "B", and wants to put
Company "B's" source on their source control server. A company had
dozens of Perforce server instances, upgrades their network, gets a more
powerful server, and decides to consolidate their Perforce servers. One
group which is using Perforce moves to another building or city, and
wants to move their source from one Perforce server to another. Or maybe
the group doesn't physically move, but their organization moves to a new
department and now that group wants to move their source to the Perforce
server used by that new department.

The thing that really worries me about the cvs2p4 conversion utility is
that it writes directly to a journal file instead of checking in and out
code, and letting Perforce handle the writing to the Journal file. I
understand why this is done. Perforce and CVS do use the same file
layout and writing to the Perforce journal is a much faster conversion
than doing multiple check ins and outs. But is the layout of the
Perforce journal file officially documented? For example, there are some
changes in the database between Perforce 2005.1 and Perforce 2005.2.
Does this include changes in the Journal file format?

In the ftp.perforce.com site, there is a schema document for Perforce
2001.1, but nothing for later releases. And, the 2001.1 documentation
doesn't document the actual layout of the Perforce journal. It may not
be that difficult to figure out Journal format, but I can't find any
official documentation.

-----Original Message-----
From: Robert Cowham [mailto:robert at vaccaperna.co.uk] 
Sent: Monday, June 26, 2006 9:40 AM
To: Weintraub, David; biswajitind at yahoo.com; perforce-user at perforce.com
Subject: RE: [p4] p4DTI in Perl ?

> P4DTI does work, but it's rather clunky. I get this same feeling about

> a lot of Perforce's utilities. The CVS to ClearCase conversion utility

> in ClearCase is built in and is very robust. The directions are 
> written into the Administrator's manual. The CVS to Perforce 
> conversion utility is a script written by a customer and maintained by

> Perforce. The directions are a README file that is sometimes light on 
> details. I was able to do a CVS to ClearCase conversion on the very 
> first try. It took several attempts to get the cvs2p4 conversion 
> utility to work the way I wanted it.
> 
> The same is true for merging two Perforce server instances. 
> You need to request a Perl script called perfmerge2.pl to do this task

> instead of a built in Perforce utility.
> 
> I want to emphasize that the scripts do there job. However, they are 
> rather clunky and give the feeling that Perforce is still not quite 
> complete. They leave the impression that Perforce isn't yet a first 
> class version control/CM system it claims to be.

The open-ness of Perforce makes lots of things possible and
traditionally they have drawn the line at a certain point and said stuff
the other side of the line *can* be scripted and looked after by others,
and therefore
*should* be (leaving them to focus on core product features). As to
where this line is drawn one we all of course have different opinions.
It's a bit like the Unix philosophy of lots of little utilities that can
be strung together with pipes etc to achieve some remarkably
sophisticated processing from simple building blocks.

The original Perforce user base tended to be pretty happy with this. As
the user base has widened, so have the expectations that more stuff is
brought into the fold and supported as core products.

In the case of conversions, I think some aspects could be better
supported and looked after.

Merging 2 servers is an example of something I wouldn't want people to
be doing very often! There are a variety of caveats, and I am quite
happy for it not to be too easy and to be done via scripts.

Ultimately the question is what features we want Perforce to implement
support as core, and what we are happy to do ourselves. It's up to us to
make sure they know what we want, and it will have some effect on the
prioritisation of releases in the future (though it is of course only
one factor in such decisions). Of course development resources are
finite, and potential enhancements are not...

Robert