On Tue, Feb 10, 2009 at 6:22 PM, jcompagner <jcompagner_at_gmail.com> wrote:
> On Mon, Feb 9, 2009 at 17:44, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Mon, Feb 9, 2009 at 11:41 AM, jcompagner <jcompagner_at_gmail.com> wrote:
>> > ahh ok
>> > Refresh revision info doesnt really say to me that it will get merge
>> > information. What does it exactly refresh besides merge? Also the
>> > commit
>> > comment and so on (because most stuff is static/fixed right?)
>> We had already added this option because it is possible for things
>> like the comment to have been edited and we are working exclusively
>> off the local cache for this information. So we updated the option to
>> also retrieve the merge information at the same time.
Thanks for the patch you submitted. We are currently working on the
SVN 1.6 tree conflicts feature in the tree-conflicts branch, but we'll
review and start committing them soon.
> the more i think about it and look how this behavior works (if i refresh
> file X and i see the right line
> and then i go to file Y that was also in that merge i see there the line
> then i think for us if i just could say where to get the merge info from it
> would be just 2 queries per project and
> you had it for all the files in 1 project that i want.
> For example we have
> /trunk/j2db and /branch/4x/j2db
> and those 2 folders contain all the merge properties for every file they
> So wouldnt it just be enough to just query the merge properties for those 2
> locations and then for every file i open thats inside that project you know
> enough info?
It sounds like you are asking for the cache to just build this
information. All I can say right now, is that I cannot see doing
that. I do not even think it'd make sense to make it a preference.
There are just too many cases where it winds up running "forever". To
get back to your specific question, other than when you are refreshing
a specific file, the cache is always built on the repository root. So
if you want a rough idea of the cache, try running:
svn log -g -rHEAD:0 url://server/repos
I am sure there are lots and lots of repositories where that will run
reasonably fast. But on other repos, it almost never ends. For
example, on SVN's own repository, without the -g option the command
takes a few minutes. With it, it will run until you kill it. So
until there is a better way to get this information, I cannot see
We added some cache maintenance in the repo browser, maybe you could
add an option there to "refresh" select folders and provide UI to
specify whether or not to get the mergeinfo? You'd still have a
problem that when the cache automatically adds new revisions, it will
do without the mergeinfo.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-11 00:45:35 CET