[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: jcompagner <jcompagner_at_gmail.com>
Date: Wed, 11 Feb 2009 16:00:31 +0100

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].
>

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1139320

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-11 16:00:41 CET

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