RE: [PATCH][RFC] svnadmin load --ignore-dates

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.fuhrmann_at_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.fuhrmann_at_wandisco.com <mailto:stefan.fuhrmann_at_wandisco.com> > wrote:

On Wed, Feb 5, 2014 at 4:02 AM, Branko Čibej <brane_at_wandisco.com <mailto:brane_at_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.

 
Received on 2014-02-05 11:58:55 CET