[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: Problem with checkout when using timestamp

From: <Sascha.Retter_at_t-systems.com>
Date: Thu, 10 Sep 2015 09:21:16 +0200


the fix suggested by Eric will work of course. But it is not very practicable in case you are running a central service that supports dozens to hundreds of projects/repositories.

In my point of view if subversion has the feature to support timestamps than either it should be prevented that log-entries with no timestamp / empty revisions are created or querying the log with entries without timestamp / empty revisions should not cause an error but somehow be ignored.

At the moment we are discussing if it is practical to import export repos with “--drop-all-empty-revs” and or filter all dumps before import.

Best regards,
**I am not subscribed so please be so kind to add me to CC regarding this topic.**

Von: Eric Johnson [mailto:eric_at_tibco.com]
Gesendet: Dienstag, 8. September 2015 18:05
An: Retter, Sascha
Cc: users_at_subversion.apache.org
Betreff: Re: Problem with checkout when using timestamp

Hi Sascha,

I believe something about about a better error report was in the works for an update. Apparently, part of what's happening is getting lost between the server, Apache modules, Apache, and the client.

You can almost certainly fix the problem by setting the svn:date revprop on the revisions missing the date properties.


On Tue, Sep 8, 2015 at 3:32 AM, <Sascha.Retter_at_t-systems.com<mailto:Sascha.Retter_at_t-systems.com>> wrote:
Hi Eric,

Thanks you! You are right I‘ve identified several entries in the revision log that look like:


And some logentries most probably have a wrong timestamp. The commit was made in September but logentries show a data in January. Do you have any idea what could be the reason for both and how we can prevent this in future?

In my point of view subversion server should at least, if such wrong log-entries could not be avoided, send a more meaningful error response than 500 Internal Server Error.


I am not subscribed so please be so kind to add me to CC regarding this topic.

Von: Eric Johnson [mailto:eric_at_tibco.com<mailto:eric_at_tibco.com>]
Gesendet: Montag, 7. September 2015 16:27
An: Retter, Sascha
Cc: users_at_subversion.apache.org<mailto:users_at_subversion.apache.org>
Betreff: Re: Problem with checkout when using timestamp

I have run into what might be the same issue. Can you perform svn log operations using timestamps? Or does that also trigger an internal server error?

My guess is that you have some revisions in your repository that are empty, probably because you did a filter on a dump, but preserved revisions. This leaves "empty" revisions around, which then trigger a problem.

I worked around the problem by adding svn:date revprops for the affected repository.


On Sep 7, 2015, at 3:08 AM, "Sascha.Retter_at_t-systems.com<mailto:Sascha.Retter_at_t-systems.com>" <Sascha.Retter_at_t-systems.com<mailto:Sascha.Retter_at_t-systems.com>> wrote:

I am not subscribed so please be so kind to add me to CC regarding this topic.

We are experiencing a problem with Subversion since some days and we are not able to recognize any changes made to the server. As soon as we try to checkout using a timestamp (e.g. svn --username some_user co https://some_user@some.host/svn/XYZ/sources/.../trunk -r {"2015-09-02 09:00:00"}) we are getting:

svn: E175002: Unerwarteter HTTP-Status 500 »Internal Server Error« auf »/svn/XYZ/!svn/me«

svn: E175002: Zusätzliche Fehler:
svn: E175002: REPORT-Anfrage auf »/svn/XYZ/!svn/me« schlug fehl: 500 Internal Server Error

If we checkout using HEAD or any revision-number everything works as expected. Problem is that jenkins’ subversion plugin uses timestamps to checkout for CI builds.

Is this a known problem? Do you know any workaround or fix? Should I fill a bug-report for this problem?

Best regards,

Sascha Retter

Received on 2015-09-10 09:21:38 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.