[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Patch] RE: Why was svn_client_mergeinfo_get_merged removed?

From: Bert Huijben <bert_at_vmoo.com>
Date: Mon, 7 Apr 2008 17:07:18 +0200

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: maandag 7 april 2008 16:38
> To: Bert Huijben
> Cc: dev_at_subversion.tigris.org
> Subject: Re: [Patch] RE: Why was svn_client_mergeinfo_get_merged
> removed?
> Bert Huijben wrote:
> > Here is a patch that reintroduces the
> svn_client_mergeinfo_get_merged() and
> > svn_client_mergeinfo_get_eligible() (former
> > svn_client_mergeinfo_get_available()) API's.
> I'm not interested in carrying forward a naive implementation of
> get_eligible(). Most of the use-cases for that functionality that I'm
> aware
> of are either a) pointless if not paired with additional info (like
> 'svn
> log' output) or b) answerable using the get_merged() API.

The log output is a very slow api when using over webdav. I know of at least one current common subversion client (TortoiseSVN) which caches svn log results to speed up the processing; and I expect AnkhSVN will do the same in a future version.

One of the problems is: A full log of *all revisions* between the first and last available revision are retrieved. For webdav this tells me that mod_dav_svn first logs all log messages in server ram before transferring the first to the webdav client. And then the client ignores most of the results.

I haven't thoroughly tested the impact in speed of a log operation without properties and files; but some tests with the commandline client seem to slow things down by about a factor of 2. (I would have expected a far worse result).

(My merge tests in the SharpSvn framework only test mergeinfo on a local repository)

I would love to have just one api with just an off switch on the svn_client_log operation, so caching can be used.. Just returning the raw revisions over the receiver. (Including the ones that don't exist on the target)

(If (b) is the way to go.. we could drop the entire svn_client api in 2.0... Everything can be accomplished by using the more low level api's ;-))

> > An other change is that svn_client_suggest_merge_sources() started
> returning
> > repository local paths instead of full urls, while the documentation
> still
> > says it should return full urls. (This change was merged to 1.5.x in
> the
> > same merge as the other changes)
> Is that true? Looking at the code for this function, there are two
> places
> where the list of returned values is appended to. Both cases are
> appending
> the result of a path-join with the repository root URL and a repos-
> relative
> path. Did some bug suddenly appear there?

It seems to only have slipped in the 1.5.x branch... (The last lines of mergeinfo.c are different in appending a url prefix)

> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On
> Demand

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-07 17:07:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.