On Fri, Nov 1, 2013 at 4:28 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>
> As long as the svn library does not provide an API to get that
> information fast, no. I won't implement this.
>
> Because as the state is now, to do that we'd have to first fetch the log
> (ok, already do), but then fetch the properties of every single file and
> every single revision to get all the required info.
I don't really think you do if you're smart about which revisions to request.
The only thing that's really interesting for the requested feature,
would be the merge info at HEAD for all branches. I don't want to know
about individual files that get merged, just when top-level project
directories got merged (or, the directory I started repo browser from,
at least). The number of branches to examine should be in the dozens
or so I would think. Then on any branches which has merge info
including the branch of interest, you just need to find the revision
which first contains the entire final revision range.
I'm not sure of the SVN internals, but even if the only way to find
the revision where the merge info started containing a given branch is
to query the properties of individual revisions, even then you don't
need to examine ALL revisions on that branch. You should be able to do
a binary search here.
So even considering a pathological example, consider a branch that has
been merged to 50 different places out of 500 branches over 10,000
revisions. Normally branches should be merged 2 or 3 places max, and
there should only be a few dozen branches, but let's work with this
for now.
500 property queries at HEAD to see which branches now have received a
merge is about 10 seconds of queries.
Now we need to find the revision on each of the 50 branches where the
merge happened. With a binary search that's a WORST case of 50 *
lg(10000) * 20ms or an additional 13 seconds.
A total time of 23 seconds for an extreme example is worth waiting for
on the occasions where the information would be useful. I think a
button on the revision graph that is OFF by default whenever you
launch the graph would be just fine.
You could make the problem much simpler, and still have a VERY useful
feature common to other revision control systems but completely
missing from TortoiseSVN, if you only allow finding merges TO a
certain branch. Most of the time I'm just interested in "what got
merged into trunk?" and not "where did this branch get merged?"
With this you would only need ONE query at HEAD on the directory of
interest to find all the directories which have been merged in,
followed by lg(10000) more requests, for a total of 14-15 queries
taking less than a second.
Additionally, for the "incoming merges" feature, I don't think you
actually even need to query every single revision.
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.mergeinfo.html
indicatesthat the command-line tools can already show merges WITH
ARROWS between two branches. Can't the revision graph just use the
same API, calling it between a branch of interest each of the other
branches shown in the graph?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3067627
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-11-01 15:34:24 CET