The ra layer function to do a date lookup currently doesn’t have a path, so we
do a date lookup on the repository level and then use it like a revision number.
To make date useful without the current limitations we should first design a
few new ra level functions that allow resolving a date (range) to something
that would be useful as input. Just fixing the backend to return some other
revision when we pass a date won’t help in any way.
Operations like
$ svn merge -r {2014-01-01}:{2014-01-31} trunk .
don’t make any sense if the first date resolves to r789 and the second to r2,
because ^/second-product /trunk and ^/dependencies/other-project/trunk just
happens to have the best match for those exact dates.
The whole idea of our current date resolving assumes that we have continuously
growing timestamps over the entire repository. If we want to change that we
should change the scope of the date lookup as the first step.
Perhaps we should try to add a path to the resolve function and see where that
helps for specific cases?
After that we can look at the problems this will introduce in the backend.
Bert
From: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com]
Sent: woensdag 5 februari 2014 06:08
To: Branko Čibej
Cc: Subversion Development
Subject: Re: [PATCH][RFC] svnadmin load --ignore-dates
On Wed, Feb 5, 2014 at 6:03 AM, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com
<mailto:stefan.fuhrm...@wandisco.com> > wrote:
On Wed, Feb 5, 2014 at 4:02 AM, Branko Čibej <br...@wandisco.com
<mailto:br...@wandisco.com> > wrote:
On 05.02.2014 03:10, Daniel Shahaf wrote:
However, 'load --ignore-dates' has another use-case: preventing the "-r {DATE}
doesn't work as intended" syndrome when loading a project's history into an
existing repository.
I would argue that this is an implementation bug, pure and simple. The fact
that it has persisted since svn-1.0 doesn't change anything. There is no reason
why -r {DATE} couldn't be made to work regardless of the ordering of the dates;
it's just that no-one has taken the trouble to actually fix the filesystem to
return valid results in all cases.
That would be extremely expensive to do in the existing backends:
We would need to effectively read all revision properties of all revs.
If we added an index ("revision order by time stamp"), we could do
better but would need to update the index upon every (rev) propset.
One more thing. Even with such index, we can only get -r {DATE} to
work but handling the date range {DATE1}:{DATE2} requires massive
changes in the underlying logic and potentially APIs. The reason is
that the date range potentially translates into a sequence of revision
ranges which brakes assumptions of path continuity in e.g. 'svn log'.
-- Stefan^2.
