[p4] Remote Depots, CVS Conversions, and Line-Endings
Stephen Vance
steve at vance.com
Wed Jun 7 16:20:42 PDT 2006
Are you aware of and have you considered perfmerge2.pl? It's a script
available from Perforce Support that merges multiple server instances
into one. That could address the multiple CVS repository issue.
Steve
David Faison wrote:
> I am helping another department deploy a new Perforce. They have
> existing archives managed under CVS that they want to bring over. The
> target platform will be Windows (out of my hands!). The original CVS
> system was hosted on Linux, then it was switched to a Windows host
> without doing any line-ending conversions on the archives.
>
> I ran the cvs2p4 utility without much trouble, but I still don't have
> much faith in the integrity of the resulting archives, because of
> potential CR/LF conversion issues that may exist. I am especially wary
> of this since the Perforce Tech Staff specifically and strenously warned
> me that archives containing inappropriate line-endings relative to the
> host platform may seem 'healthy' but can still become corrupted. These
> archives are guaranteed to be 'inappropriate' because they have already
> been blended to begin with.
>
> The thought of trying to straighten out all the line endings became an
> undesireable option when they (P4TechStaff) explained that CVS maintains
> binary data in archives sandwiched between textual control records -
> meaning that the binary archives would require selectively converting
> only the textual regions. Which is more than I want to chew on if I
> don't have to!
>
> On a separate note: I have several separate CVS repositories that I must
> assimilate into one server. Running the cvs2p4 utility separately
> creates separate databases.
>
> My solution to all this is put all of the 'converted' CVS archives into
> a separate, remote depots and then branch them back into a single
> 'working' server. This makes all the history visible, but the underlying
> archives are read-only, and therefore will never degrade because of
> activity against them (i.e. if they're good today, they're good
> forever!).
>
>
> My question is: what are the downsides that I might not be seeing to
> this approach?
>
> Thanks in advance,
> David Faison
> Photon Research Associates
>
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
More information about the perforce-user
mailing list