"Stefan Küng" <tortoisesvn@gmail.com> wrote 05.10.2007 10:14:03:
> how did you get the merge tracking information if (as you mention
> below) you don't use svn_client_log4() yet? Or do I misunderstand
> something here?
All I did is to extend the data container: similarly to the changed
path list, it can hold a list of merges per revision. Every entry
in this list has the form (fromPath, toPath, fromRev, numRevs).
The same is true for user-defined revprops.
My focus was clearly on finishing the storage format, containers
and update functionality -- even if we should choose not to use
certain features in 1.5. Also, the query classes have not been
enhanced, yet.
So, what remains to be decided upon is how we match the data we
get from the current svn_client_log4() implementation to this format.
I do not know, for instance, whether the merged revisions depend
on the path passed to the function(). One possibility to store its
result may be in the form of (NO_PATHID, NO_PATHID, fromRev, 1).
We could safely identify such data in later versions and replace it
with more precise information as soon as we can get it.
> > * Log caches now support partial information (e.g. merge info
> > not available for a given revision)
>
> What happens if merge info is not available for a revision? Does the
> cache re-fetch it from the repository?
The cache is always passive: It is always the query that will detect
and add missing information. Today, this happens for revisions that
have not been cached, yet. In future, it must check whether the
requested data (header info, changes, revProps, merges) is available
and fetch it from SVN as necessary.
In other words, we can now populate and update the cache on a
sub-revision level.
> > To do before merging into /trunk:
> >
> > * Refresh in log dialog shall update the head revision
> > (e.g. "any new revisions?") as well as update authors and
> > comments in the revisions shown.
>
> I think to update authors/comments, the users can use the 'clear log
> cache' in the settings dialog. A refresh in the log dialog should not
> invalidate the cache IMHO.
Updates work as follows: A temporary CCachedLogInfo instance is created
and filled with the new data, e.g. from SVN query. After that, this temp.
instance is passed to the Update() method of the existing cache together
with a combination of flags that indicate what "fields" shall be copied.
If the user should cancel the update operation, the portion that already
got fetched can safely be applied to the existing cache.
For an author / comment update, we would not need to fetch all changed
paths etc. "Refetch"ing header info only should, therefore, be much
faster than the initial "fetch".
Following the discussion about how and when to update existing cache
data, I will implement the following:
* F5 / Refresh will just look for a new HEAD revision and fetch all
data between old and new HEAD
-> will be implemented before the merge
* Ctrl-F5 / Refetch will update the header data (author, timestamp,
comment) for the revisions *shown* in the log dialog (the cache may
contain much more).
-> will be implemented after the merge
(I want the other changes to be tested asap)
-- Stefan^2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Oct 5 21:42:59 2007