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].
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1139335
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-02-11 16:10:40 CET