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

Re: [Subclipse-users] CollabNet merge tool on Subclipse 1.6, Eclipse 3.5 OS X Carbon, javaHL

From: Bradley Wagner <bradley.wagner_at_hannonhill.com>
Date: Fri, 10 Jul 2009 17:50:32 -0400

>
> Yes, it should work. All my servers are now on 1.5+ though so harder

to test. But tigris was on 1.3 until December and openCollabNet was

on 1.4 until March. And this all worked fine. Of course that was

with earlier versions, so maybe something has broken.

Well, I still haven't had a chance to upgrade to svn 1.6 but I have
some more insight into this problem.

It appears to only happen when I try to merge from my trunk. I tried a
merge into a working copy of my trunk from a branch and it worked
fine. However, if I try to merge
from my trunk into a working copy of a branch I get the blank revision
screen.

I have my repos setup with a number of top-level project folders so maybe
that has something to do with it also.

- Bradley

On Thu, Jul 2, 2009 at 1:41 PM, Mark Phippard <markphip_at_gmail.com> wrote:

> On Thu, Jul 2, 2009 at 1:36 PM, Bradley
> Wagner<bradley.wagner_at_hannonhill.com> wrote:
> > The author dropdown is empty and inactive meaning I cannot select it.
> >
> > I'm wondering if it has to do with the combination of having a client
> that
> > does support it (1.6) and a server that doesn't (1.3.2). Although, you
> said
> > your project was using 1.3.x on the server side while the client was
> under
> > development.
>
> Yes, it should work. All my servers are now on 1.5+ though so harder
> to test. But tigris was on 1.3 until December and openCollabNet was
> on 1.4 until March. And this all worked fine. Of course that was
> with earlier versions, so maybe something has broken.
>
> > I switched over to our svn 1.6 test server and it of course works much
> > better. However, I ran into another strange thing when attempting to
> merge a
> > single revision from my trunk into a release branch. Basically, the Merge
> > Result showed a single file updated, the summary at the end showed a
> single
> > file updated, but when I synchronized my branch there tons of outgoing
> > changes as if it had merged many revisions. The SVN console seems to only
> > indicate one:
> >
> > merge -c 12605 http://bradley.wagner@dev.company.com/repos/project/trunk
> > /Users/bradley/Java/workspace/project_stable_test
> > --- Merging r12604 through r12605 into
> > /Users/bradley/Java/workspace/project_stable_test
> > U
> >
> /Users/bradley/Java/workspace/project_stable_test/src/java/com/company/project/view/struts/form/entity/FileForm.java
> >
> > Any ideas on this one? Sorry for hi-jacking of my own thread.
>
> This is normal SVN merge behavior. Looks like you are going to have
> fun when you upgrade :)
>
> You probably have a ton of files that have acquired the svn:mergeinfo
> property. Probably empty. Probably created by copying/renaming
> files. SVN 1.5.6 made changes to stop doing this. You should
> systematically remove all occurrences of that property in your
> repository ASAP, and make sure no one is using earlier 1.5.x clients.
>
> When the svn:mergeinfo property exists, every merge will update those
> properties.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ------------------------------------------------------
>
> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2367527
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subclipse.tigris.org].
>

-- 
Hannon Hill - CMS Experience You Can Trust
(678) 904-6900 ext 115
http://www.hannonhill.com
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2370479
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-07-10 23:50:57 CEST

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

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