Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> Stefan.Fuhrmann_at_etas.com wrote:
> > Stefan Kueng <tortoisesvn_at_gmail.com> wrote:
> >> Seems the log cache can't handle date revisions?
> >
> > That is correct.
Hm. Actually, it should have worked in many cases.
It did at least on my machine: The DecodeRevision
method has a fallback that uses svn info to translate
the revision. That should only fail if the repository
cannot be reached or if the date lies before the respective
path's creation.
> >> With the next nightly build (> 15028):
> >> * show log on the TSVN working copy
> >> * click arrow of "Show All" button, select "revision range"
> >> * enter {2008-01-01} and {2009-01-01} in the from/to fields
> >> * click OK.
> >>
> >> I remember that the log cache isn't designed to handle date revisions,
> >> but could you maybe implement a workaround so that if date revisions
> >> are specified that the cache is not used?
> >
> > I think the log cache can be taught to interpret
> > date revisions. Here is the plan:
> >
> > * CLogCacheQuery translates date revisions to
> > actual revision numbers (just like it would
> > for HEAD, peg/path etc.) and runs the actual
> > query after that.
> >
> > * Date revisions can be translated as follows:
> > - find the latest revision before the date.
> > Start at revision 0 and increment until found.
> > I guess that is what SVN still does even
> > if the history is non-contiguous?
> > Alternatively, find the closed match.
> > - check whether the revision found equals HEAD
> > or whether the next revision is in cache.
> > -> translation successful, otherwise failed
> > - if the translation failed, ask the server
> > to translate the date revision
> > - when in off-line mode, proceed with whatever
> > revision has been found
> >
> > For non-contiguous history, e.g. after merging
> > repositories, (some) date revisions are ambiguous.
> > In that case, the log cache might return different
> > results as a native query.
> >
> > I should be able to implement that this weekend.
>
> Great!
Implemented and tested with r15059. There are sooo
many special and edge cases. Hopefully, I got them all.
> A few things more (sorry):
> * svn_client_log4 is now deprecated. But there's not much of a change to
> svn_client_log5 - you could just implement a wrapper around it
Done in r15066.
> * since you reorganized the lib projects, some files in the solution
> explorer are not correct anymore (header files listed there don't exist
> anymore)
Fixed in r15068.
> * the lib projects have _CONSOLE defined - I don't think that's necessary
Removed in r15067. I didn't explicitly add those. Since
I use those libs in some other project, however, they
might be needed again at some time in the future.
-- Stefan^2.
Received on 2009-01-11 14:08:26 CET