> Now i go back to the branch and i say to that eclipse project merge with
> > /trunk
> >
> > Now getting the revisions takes ages.. :(
> > And when it comes back i see that it got all the revisions from 1 to
> 26020
> >
> > The first question is why is that?
>
> Did you specify the wrong path? Such as /trunk rather than
> /trunk/ProjectName?
>
no it is trunk
because the merge later on worked fine, i clicked on the latest revision i
wanted to merge and it merged it perfectly
this is the setup:
we had
/trunk/project1/
/trunk/project2/
then we branch and if we branch we just copy the whole of trunk to a
branches/xxx
so we get
/branches/V50/project1/
/branches/V50/project2/
then i created a new workspace in eclipse and i checked out:
/branches/V50
then i have 1 project in eclipse that has /project1/ and /project2/ as
folders.
now i imported those projects as root projects (this is more cumbersome to
do in eclipse 3.5 then it was in 3.3 by the way but thats another story not
related to subclipse)
but that importing of projects in eclipse is not related at all to this
discussion
Now i make in trunk many changes of 3 or more projects and i commited that
as one commit
then in the new branch workspace i go to the V50 project that is just the
/branches/V50 folder in svn
then i do merge and now i must select trunk.. because there it is where it
comes from. /branches/V50 was a few revisions ago exactly a copy of /trunk
and when it finally has all the logs i can select the one i want and it
merges it just fine, so i am not on the wrong path because then the merge
shouldnt map exactly on the right files in my workspace.
> Just guessing, as you know we do not control what comes back from the SVN
> API.
>
> > That looks like an error to me because revision 1 -> 26000 (so excluding
> the
> > last 20) is not what we want to merge because that is what the branch
> > already is (its created at 26000)
> > So it should only get revisions from the revision the branch is created
> of
> > until now.
>
> Correct.
>
> > the second thing is even if it want to get that many shouldnt we make the
> > merge client so that it only at first gets the top 20 (like history view)
> > and only when a user presses get next it gets 20 more?
> > Then that getting revisions is way faster then it is now.
>
> We considered that when designing it. I felt it should get all the
> eligible revisions. Unlike viewing history of a file, when merging it
> seems just as likely that someone is going to want and older revision
> as a newer one. And hopefully the SVN filtering of eligible revisions
> is already reducing the list.
>
> I do not think the fact that you incorrectly got back 26,000 revisions
> you shouldn't have should factor into this.
>
Now it was really seen, because it got all 26K revisions
But also in our normal project1->project1 merge what i did it got slower and
slower and the revisions it got back where already hundreds
because our patch branches do get quite some time (we still support 3.5 of
our project that we released years ago, and we are already on 5.0 now and
trunk is already 5.1) so there are loads of commits on them
A co worker of mine doesnt like to use the merge client just because of
this, it takes to long compared to quickly doing it with revisions on the
command line
(but now he can skip or forget if he is not carefull)
And that takes to long is pretty much 1 thing, getting the logs (and yes i
do think that the actual merge also does take more time that i expect it to
be)
johan
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2418990
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-11-17 16:55:38 CET