Re: Log caching vs. merge tracking

Stefan.Fuhrmann@etas.de wrote:

> my belief is that TSVN needs full merge tracking
> information for features like the revision graph.
> That is: all svn:mergeinfo property changes for
> all paths in all revisions (if they changed).

Not just the revision graph. The merge dialog could benefit from this too.

> Even the newest SVN log API does not provide
> that information: it does not tell what revisions
> have been merged / unmerged from what path
> to where.

Are you sure? AFAIK the new log API will provide every log entry from
every merge as 'children', i.e., there's a flag indicating that a log
entry has children, then the next log entry (or entries) which are
delivered are those children.

> There seems to be no API to get that information
> *efficiently*, i.e. without zillions of individual calls
> to get_merge_info (?) taking hours for a single
> "large" revision. I will ask the SVN devs about it.

If you just want the svn:merge property, I think one call to the HEAD
entry to get that property should be enough. Because the latest entry
will contain all previous merge info too.
That means maybe we don't need to cache this after all.

But what we do need to cache is the 'children' entry in the extended log
entry struct, and we also need to change the log cache to send the child
entries after the parent entry like the new log API does.

> However, I think we do need the full merge info.
> Therefore, I added the respective data containers
> and interfaces to the log caching infrastructure.
>
> My questions:
>
> * Do you agree that we should store / process
> the whole merge info?

Yes. But maybe not the svn:merge property.

> * How would the merge info be represented in
> e.g. the log dialog?

I was thinking of adding a tooltip to the top view which would tell the
revisions which got merged and from where.
And in the log message control, some kind of separator after which the
log messages of the merge would be shown.

But maybe that's not really necessary. If we just use the latest
svn:merge property (which IMHO is the information which really is
important for the user), we don't have to change the log dialog at all.
We can use that information where we really need it (e.g., the merge
dialog).

> * Is it o.k. to stick with the current log interface
> and not to mimic the latest "include merge-tree"
> log feature?

I haven't done any tests yet, so I don't know how the performance of the
'include merge-tree' switch of the new log API is. But I think we should
really mimic the Subversion API here.
If not, we'd have to write a separate method SVN::PlainLog() (or
something like this) which would use the new API but not use the cache.

> If questions 1 und 3 are answered "yes", I can
> merge the latest changes (merge-tracking and
> cache updates) to trunk.

Maybe we should first decide how exactly we're going to use the merge
information in TSVN, then we can decide what we need cached and what not.

I'll try to write some requirements about the merge info we really need
and will send them here for discussion.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org