[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:35:46 -0500

I am commenting on the general building of the cache. You seemed to
desire (quite resonably) that the merge info was already there without
the refresh. I explained why it is not currently done and talked
about ways it possibly could be.

If you want to explore new ways to refresh existing revisions then you
can do so. Given that you can now select multiple revisions, I do not
see how your suggestion is needed though since it would just be the
equivalent of selecting the revisions for a branch in the graph. So,
assuming it is needed, why not just make easier ways to do that in the
UI and let the existing feature do the work?

On Wed, Feb 11, 2009 at 10:10 AM, jcompagner <jcompagner_at_gmail.com> wrote:
> i dont want to refresh a specific revision
> I want to refresh a specific file in a specific trunk, tag or branch (so all
> the revision of the file in trunk or in a branch)
>
> for just getting the merge info this would be (on 1 file in a specific
> branch or just trunk) be the fastest way as far as i see
>
> svn log -q -g -rHEAD:0 url/x/branch/y/File.java
>
> If we could merge that output (with or without the -q) back into the cache
> for that specific file, it would be fast and it would work for me
> But i maybe just dont see the whole picture how the cache is build, i will
> dive into this a bit deeper.
>
> johan
>
>
> On Wed, Feb 11, 2009 at 16:03, Mark Phippard <markphip_at_gmail.com> wrote:
>>
>> 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].
>
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1139402
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-11 16:35:59 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.