Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

richardc (1662)

richardc
  (email not shown publicly)
http://unixbeard.net/~richardc/

Journal of richardc (1662)

Sunday April 21, 2002
03:29 PM

It's no good Jim, she just cannae take it.

[ #4350 ]
I've now resolved most of the patch applying issues by standing on Andreas's shoulders and tweaking his patchaperlup script. This taken care of I've been hammering a local CVS repository with patches from 5.7.1 to the edge of blead, some 5472 changes.

CVS is grinding to a halt.

Perforce, the revision control software used to manage the perl5 sources, has this wonderful feature of numbered change sets. If you hang around in the wrong places you'll hear references to perl@16047, or some other number, which corresponds to a change number on the development track.

CVS doesn't have changesets. This is a major bummer, especially if you're trying to do an anonymous cvs mirror of the perl repository. You really do need some way to emulate them so that people can easily get back to a historic state based on the change number. All CVS has for this is tags.

When you tag a CVS module every file in the module is modifies to reflect the tag. perl@16047 has 2771 files. That's 2771 files to completely rewrite after each patch.

My repository at 12513, roughly 2,500 patches along, has 152M of data in it. 152M of files get rewritten for every applied change. This is a slight IO hit.

Moral: CVS just doesn't blummin scale to thousands of tags.

I'm going to have to have a think about this, see if it's possible to to simulate change sets without using tags. I do so hate having to think.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.