Re: log -g performance

Karl Fogel wrote:
> So when a commit does both (that is, commits the result of a merge or
> merges, *and* includes new changes), should the marker be set? What's
> the use case? (Quoted context didn't say.)

To summarize and motivate the RFE(s) in short: Especially for GUI
clients it can be useful to retrieve mergeinfo for a range of revisions
(even for the whole repository), however currently there is no efficient
way to do this. The best approach I can currently see is to use log -g
but it means a rather large overhead for this task. So following
enhancements could be helpful here (and they can be more or less used to
substitute each other):

* log (without -g) reports a "marker" for *every* revision whether
   mergeinfo is present in the repository for the logged path (and
   its children). In this way the client knows for which revisions it
   should query for mergeinfo.

* log -g has an additional --depth parameter, --depth=0 would report
   no merged revisions, but the same marker as suggested above.

* The get-mergeinfo command (I'm referring to that of the svnserve
   protocol and its DAV counterpart) supports fetching mergeinfo for
   a range of revisions.

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Karl Fogel wrote:
> Marc Strapetz <marc.strapetz_at_syntevo.com> writes:
>>> One of the things I was thinking was that it would be nice (assuming
>>> it is not expensive), if a normal svn log could just return some kind
>>> of boolean for each revision that indicates if the revision was the
>>> commit of a merge.
>> That would be helpful as well. The suggested depth parameter requires
>> a protocol change from client to server and in case of depth=0
>> probably also from server to client. How about this mergeinfo marker
>> -- can it be introduced safely without breaking older clients?
>>
>> Can we get this topic into the issue tracker?
> 
> Let's discuss it here first, and if we decide to do it, then file an
> issue.
> 
> So when a commit does both (that is, commits the result of a merge or
> merges, *and* includes new changes), should the marker be set?  What's
> the use case?  (Quoted context didn't say.)
> 
> Best,
> -Karl
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org