[darcs-users] darcs patch: Recognize a special DARCS_TESTING_PREFS_... (and 2 more)

[Eric Kow]

On Wed, Jul 15, 2009 at 17:39:53 +0200, Petr Rockai wrote:
> > The candidates appear to be
> >   unrecord-setpref.sh
...
> >   workingdir.sh

> Ouch! I haven't seen anything like this on neither POSIX nor Win32... Anything
> specific?

The failing test was network/get.sh and it appears to have nothing to do
with your patches.  I wish our shell harness would report the tests it
was running as it was running them.  Some sort of buffering seems to be
going on somewhere.

Anyway, here's the failing test makes sure that obliterating the last
tag and getting it back gives you exactly the same inventory as just
getting the last tag.  But somehow this fails.  The difference is a
pointer to the sub-inventory generated for tags.

diff -u temp2/_darcs/hashed_inventory temp3/_darcs/hashed_inventory

And here's the difference it reports:

 Starting with inventory:
 -0000001196-425caaa241860e2c915cde3185fe9bb6d922f9620a9db9a4b91742a59aaf1f57
 +0000142238-9a6a29d875308440d1e6b140978a7cb47d0fcd50e54ca8dbe43567e334205b41
  [TAG 2.2.98.3
   Petr Rockai <me at mornfall.net>**20090710143916
     Ignore-this: 58721594f0f0779473e3e88e9fc4bb29

This sort of thing has happened a couple of times before around the time
of a release.  It seems to coincide with the case where we pull in tags
and patches from the release branch on top of patches that the release
branch does not have.

I confess that this has not only happened before (during releases), but
that I had also always just thought it harmless and glossed over the
difference by optimizing the darcs.net repository.  That, of course, is
stupid; one should always make use of errors, not make them go away. 

So let's sit down and think about this some more.

I attach the two gzipped inventories.  The temp2 one corresponds to the
obliterate and pull approach, and the temp3 to the plain old get
approach.  Note that the temp3 one appears to a superset of the temp2
one.  Somehow the temp2 approach breaks up the inventories more that
than the second approach.  What exactly is going on?  And why does
optimizing the darcs.net repository make this error go away?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0000001196-425caaa241860e2c915cde3185fe9bb6d922f9620a9db9a4b91742a59aaf1f57
Type: application/octet-stream
Size: 656 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090717/ffffe72c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0000142238-9a6a29d875308440d1e6b140978a7cb47d0fcd50e54ca8dbe43567e334205b41
Type: application/octet-stream
Size: 60270 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090717/ffffe72c/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090717/ffffe72c/attachment-0001.pgp>