Re: Conversion of Perl Perforce repository to Subversion - Part 1

Barrie Slaymaker <[email protected]> Mon, 31 May 2004 10:53:28 -0400
Newsgroups gmane.comp.version-control.revml
Message-ID <[email protected]>
On Mon, May 31, 2004 at 12:14:09AM +0100, Chia-liang Kao wrote:
> > The RAM limitation should not apply to other drivers, though I can't
> > speak for the svn drivers.  If you're seeing massive RAM use when using
> > VCP::Source::{p4,cvs,vss} and VCP::Dest::p4, then I need to get to the
> > bottom of it.  But I don't think that's what you're doing.
> 
> It appears the leak comes from VCP::Dest::svk. Converting from the
> same cvs source, p4 dest stays around 15M (one of the tests I
> mentioned in the previous mail), but the svk dest grows to 60M or so
> at around 10% of the conversion. I'll take a look and try to fix it.

Thanks for testing!

> btw, I noticed VCP is no longer indexed by CPAN.

We deleted it because Perl has changed so rapidly in non-backcompat ways
that we can't support VCP with a wide range of Perls and a wide range of
whatever-module-a-user-has-installed.  PM_PREREQ only handles "older not
good" requirements, for instance and we've had conditions of "newer not
good" that have surprised us.

So, for end users, we plan on providing executable binaries and perhaps
a "fat" script version without developer prereqs but with all required
non-CORE modules.  This means that having it on CPAN inevitably leads to
the "ok, where did you get your version from" question before we can
debug the problem.

Once VCP passes 1.0 succesfully, we may go back and and provide better
support for CPAN.  Until then, syncing from public.perforce.com:1666's
//public/revml/... tree is the only/best way for developers to get the
//code.

Sorry for the inconvenience.

- Barrie