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

Re: [Subclipse-dev] revision graph: shouldnt it be possible to also show the merge lines?

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 11 Feb 2009 10:03:23 -0500

When the cache is being built, including when it looks for new
revisions since it was last built, it uses the repository root to
build the cache. It has to do this to be able to to discover copies.

When you are refreshing a specific revision, I am not sure if it uses
the path or the repository root, but it would not matter in either
case since it is just a specific revision(s).

Mark

On Wed, Feb 11, 2009 at 10:00 AM, jcompagner <jcompagner_at_gmail.com> wrote:
> Are you saying you need to run it on the root of the repo?
> why is that? Or do you just mean what i test below?
>
> i am testing this now:
>
> svn log -g -rHEAD:0 url/x/branch/y/File.java
>
> svn log -g -rHEAD:0 url/x/trunk/y/File.java
>
> i tried this on files with quite some history on a remote (over the
> internet) repository
>
> and within a few second it does return.
>
> But this still can be a manual thing to do i guess
> just make the branches/tags in the graph selectable and say refresh the
> whole branch/tag? (that does the query above?)
>
> johan
>
>
> On Wed, Feb 11, 2009 at 14:50, Mark Phippard <markphip_at_gmail.com> wrote:
>>
>> On Tue, Feb 10, 2009 at 6:45 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> > 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
>> >> also)
>> >> 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
>> >> hold.
>> >> 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".
>>
>> Actually, if you and some others were to say that running svn log -g
>> on the root of their repository is not too bad for them I could see
>> allowing a preference for this. It would be important for a warning
>> dialog to be popped up when/if someone tried to turn it on though.
>> Obviously if someone just sees a checkbox that says "Include merge
>> information on revision graph" they are going to check it. We'd need
>> to do our best to let them know how bad a choice that can be.
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>> ------------------------------------------------------
>>
>> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1138886
>>
>> To unsubscribe from this discussion, e-mail:
>> [dev-unsubscribe_at_subclipse.tigris.org].
>
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1139326
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-11 16:03:34 CET

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

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