Hi Sascha,
I suspect the answer is much worse than you suspect.
Any "time-based" Subversion operation is almost certainly going to yield
the wrong answer if you ever merge two repositories with a dump/load
process. That's because the log operation doesn't scan all entries to find
the ones with the given date. I believe it just assumes that the commits
are chronologically ordered, and does a binary search to find the right
start & end point.
Thinking about this problem a little bit, I suspect the only long-term
stable solution in Subversion is probably to stop using monotonically
increasing revision numbers to reference changes. Instead, they need to be
referenced by hash or some equivalent (and then indexed). For example, if
you have a project that you dump and load into a new repository, you can
either add all those changes at the end of an existing repository - thus
messing up any date operations - or you could try to be clever, and
integrate them all by time sequence, so that the chronology is now
preserved, except that messes up all the revision numbers, so any existing
Subversion URLs that reference a revision number would now be invalid. That
doesn't mean that revision numbers go away (thus breaking every client out
there!), just that they would be an internal - and officially unstable way
of referencing changes.
There's a half-way solution that solves the issue for the date problem.
Subversion could maintain an index of entries by time, so that it can
quickly and correctly answer time-based questions, even when repositories
have been merged. That mostly solves the problem - time-based operations
work, and revision #s for the repository being imported into are still
stable. However, revisions #s from the repository being added will not be
the same as they were in their original repository. For that, I think you
have to go to the hash solution.
Eric.
On Thu, Sep 10, 2015 at 12:21 AM, <Sascha.Retter_at_t-systems.com> wrote:
> Hello,
>
>
>
> 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,
>
> Sascha
>
> ***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.a
> pache.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.
>
>
>
> Eric.
>
>
>
>
>
> On Tue, Sep 8, 2015 at 3:32 AM, <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:
>
>
>
> <logentry
>
> revision="24290">
>
> </logentry>
>
>
>
> 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.
>
>
>
> Sascha
>
>
>
> *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:* Montag, 7. September 2015 16:27
> *An:* Retter, Sascha
> *Cc:* 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.
>
>
>
> Eric
>
>
>
>
> On Sep 7, 2015, at 3:08 AM, "Sascha.Retter_at_t-systems.com" <
> Sascha.Retter_at_t-systems.com> wrote:
>
> Hello,
>
>
>
> 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 18:02:12 CEST