> Hans-Emil Skogh wrote:
>>> One way to get the required information would be to use the information we
> get from the log. If we see>that the path that we are examining has got
> property changes in a revision, we could get the properties>and then
> specifically check for changes in svn:mergeinfo. Any changes to that propery
> would translate>to a merge operation performed in that revision.
>>> This would make the revision graph even slower, as we would need to fetch
> all property changes made>to a path, but I think it would be a possible
> solution. Or is there a smoother way to get at this>information?
> Hello Hans
> As far as I can see we can get the required merge information by using the
> following SVN command
> * SVN LOG -G -V -R X:Y * where X and y is a revision range involved.
> The above command will fetch the history of each revisions along with its
> corresponding mergeinfo (if any). I tried
> svn log -g -v -r 39834 http://svn.collab.net/repos/svn/branches/1.6.x >
> http://old.nabble.com/file/p26844541/MergeInfoUsingLOG%2BG.txt > MergeInfoUsingLOG+G.txt
> and attached the output file here.So I dont think so we should do log ,
> check for Properitychanges or so.
Sure, fetching the log can also give you *some* merge info. But nearly
not enough for showing the revision graph.
Because the merge info is only shown for the path you show the log for,
not all related paths.
Imagine you show the graph for /trunk. You'd want to see the merge lines
where you merged something *from* trunk to all branches you created from
trunk. But the log for /trunk doesn't show that merge info. Only the log
for one of the branches will show you which revisions got merged *to*
What you would have to do to get all merge info is to first find out all
branches that were made from /trunk (that's something the rev graph
already does). Then you'd have to fetch the log (again) for every single
one of those branches with merge info included to get that merge info.
And that could take a very, very long time. Especially if you have a lot
of branches and tags (have a look at the rev graph for the TSVN repository).
> So I am right now analysing TSVN Cache structure, Once it is known we can
> just store the collected data into the cache and retrieve it back for
> generating graphs.
> 1. First thing is that we should analyse how exactly the cache file is
> created from log and how can we
> add data into that cache so that it is not breaking the backward
> compatibility. ( Must do some tweaks to CRootOutputStream or any class
> related to that) I am looking at that right now.
> 2. Once that is done, We need to study how the data is again retrieved from
> that cache file(Using Indexpairdictionary and revision index)
Questions about the cache structure should be best answered by Stefan^2 :)
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net