File-Rsync-Mirror-Recent

 view release on metacpan or  search on metacpan

Todo  view on Meta::CPAN

	  path: id/J/JO/JOHND/CHECKSUMS
	  type: new
	Dre-0:
	  epoch: 1237400807.97514
	  path: id/M/MI/MIYAGAWA/CHECKSUMS
	  type: new
	Dre-1:
	  epoch: 1237400817.94363
	  path: id/X/XI/XINMING/Catalyst-Plugin-Compress.tar.gz
	  type: new
	Eintervals:
	  -
	    - 900644040
	    - 900644040
	  - []

	and it is reproducable.

	Why does the mirrorer not fetch a newer Z file? It is 18 hours old while
	pause has a fresh one.

	FIXED, it was the third anded term in each of the ifs in the IV block in
	_register_one: with that we make sure that we do not stamp on valuable
	interval data.

2009-03-17  Andreas J. Koenig  <andk@cpan.org>

	* done: verified the existence of the floating point bug in bleadperl
	and verified that switching from YAML::Syck to YAML::XS does not resolve
	it.

	BTW, the switch was doable with

	perl -i~ -pe 's/Syck/XS/g' lib/**/*.pm t/*.t

	and should be considered as a separate TODO

	* todo: integrate a dirty update with two aggregate calls before
	unlocking for frictionless dirtying DONE

	* todo: start the second rsync daemon on pause DONE

	* todo: move index files to .recent: this cannot simply be done by
	setting filenameroot to .recent/RECENT. Other parts of the modules rely
	on the fact that dirname(recentfile) is the root of the mirrored tree.

2009-03-16  Andreas J. Koenig  <andk@cpan.org>

	* What was the resolution of the mirror.pl delete hook bug? Do we call
	the delete hook when pause removes a file from MUIR?

	* Today on pause: Updating 2a13fba..29f284d and installing it for
	/usr/local/perl-5.10.0{,-RC2}

	TURUGINA/Set-Intersection-0.01.tar.gz was the last upload before this
	action and G/GW/GWILLIAMS/RDF-Query-2.100_01.tar.gz the first after it

2009-03-15  Andreas J. Koenig  <andk@cpan.org>

	* currently recent_events has the side effect of setting dirtymark
	because it forces a read on the file. That should be transparent, so
	that the dirtymark call always forces a cache-able(?) read.

	* The bug below is -- after a lot of trying -- not reproducible on a
	small script, only in the large test script. The closest to the output
	below was:

	#!perl
	use strict;
	use Devel::Peek;
	my $x = "01237123229.8814";
	my($l,$r);
	for ($l,$r) {
  $_ = "x"x34;
	}
	($l,$r) = ($1,$2) if $x =~ /(.)(.+)/;
	$r = int $r;
	$l = "1237123231.22458";
	$r = "1237123231.22458";
	1 if $l/1.1;
	Devel::Peek::Dump $l;
	Devel::Peek::Dump $r;
	Devel::Peek::Dump $x = $l <=> $r;
	die "BROKE" if $x;
	__END__

	The checked in state at c404a85 fails the test with my
	/usr/local/perl-5.10-uld/bin/perl on 64bit but curiously not with
	/usr/local/perl-5.10-g/bin/perl. So it seems the behaviour is not even
	in the test script always consistent.

	* Todo: write a test that inserts a second dirty file with an already
	existing timestamp. DONE

	* Bug in perl 5.10 on my 64bit box:

  DB<98> Devel::Peek::Dump $l
	SV = PVMG(0x19e0450) at 0x142a550
	  REFCNT = 2
	  FLAGS = (PADMY,NOK,POK,pNOK,pPOK)
	  IV = 0
	  NV = 1237123231.22458
	  PV = 0x194ce70 "1237123231.22458"\0
	  CUR = 16
	  LEN = 40
	
	  DB<99> Devel::Peek::Dump $r
	SV = PVMG(0x19e0240) at 0x142a3e8
	  REFCNT = 2
	  FLAGS = (PADMY,POK,pPOK)
	  IV = 1237123229
	  NV = 1237123229.8814
	  PV = 0x19ff900 "1237123231.22458"\0
	  CUR = 16
	  LEN = 40
	
	  DB<100> Devel::Peek::Dump $l <=> $r
	SV = IV(0x19ea6e8) at 0x19ea6f0
	  REFCNT = 1
	  FLAGS = (PADTMP,IOK,pIOK)
	  IV = -1



( run in 0.826 second using v1.01-cache-2.11-cpan-c966e8aa7e8 )