As seen on TWiki:Plugins/RevisionLinkPlugin and reported on TWiki:Plugins/RevisionLinkPluginDev, the viewfile retsurns r4 of the zip file, which is the latest rev in .zip,v file. That rev is an old version from 2003. The latest version uploaded by Kenneth on 18 May 2006 is not stored in teh ,v file. The attached zip file is the correct latest version, e.g. if dowloaded via pub.

It looks like the BuildContrib updated the topic, attached the .zip and other files, but did not update the ,v files.

Not sure if this is a core bug or a BuildContrib bug.

-- PTh

All the BuildContrib does is to use the upload URL to upload the zip file. The updating of the ,v file is the responsibility of the core.

Changing to Engine.

It would be helpful if you could describe how to reproduce this problem.

CC

Could it be the contrib not waiting for completion of the upload script execution? If interrupted, it could stop the script half way.

-- PTh

I looked at the request sent by the contrib; it is a standard upload, and provides the same parameters as an upload from the browser. It waits until completion, and checks the returned status code.

    $response =
      $userAgent->post( $this->{TWIKIORGSCRIPT}.'/upload/'.$web.'/'.$to,
                        [
                         'filename' => $filename,
                         'filepath' => [ $filepath ],
                         'filecomment' => $filecomment
                        ],
                        'Content_Type' => 'form-data' );

    die 'Update of '.$filename.' failed ', $response->request->uri,
      ' -- ', $response->status_line, $NL, 'Aborting',$NL, $response->as_string
        unless $response->is_redirect &&
          $response->headers->header('Location') =~ /view([\.\w]*)\/$web\/$to/;

It works perfectly for uploads to my local TWiki.

CC

Just checked again with an upload to a different server, and it works fine. AFAICT the uploads to t.o are also working fine. Discarding until someone can provide specifics on this error.

CC

Hmm, what is the point of submitting reports of intermittent errors if they get discarded?

-- PTh

From the help text of this Bugs application.

Waiting for feedback - the report was insufficient to analyse the issue, and more feedback is needed from the reporter. Once the reporter has added feedback they should flip the state back to "New"

Discarded the issue was already fixed, or it's a duplicate, or an RTFM.

This one I guess is in the grey area between. As a reporter I know how having a bug report discarded is a bit like having a fist on the nose if you feel that the bug is important and you are willing to try and report more data. On the other hand we cannot have 200 bugs reports rotting forever waiting for feedback. But when there is a doubt use the Waiting for Feedback option and if the reporter is not back within a week then discard.

For this particular bug I bet the problem is not the BuildContrib but the stability of twiki.org. When I uploaded RevisionLinkPlugin with the build script earlier this year, twiki.org may simply have failed on the server side and it is hard to see how an automated upload script within reason should be able to cope with that.

We have seen so many glithces on twiki.org. Problems with loading CSS. Problems downloading files. Problems with pages not completing download. Saving occationally has failed (time out no explanation) etc etc. Pages views time out. Maybe twiki.org needs an 1000000 km service check. What version is it at right now? Is it at 4.0.4? Has hotfixes been applied.

KJL