Thanks, Mark:
It appears as though my "small issue" is more of a big deal than my
large issue. :-)
If I am reading the supplied blog post correctly
1) the most likely cause of this is that a subclipse upgrade I applied
some time ago has left my system in this state
2) there is no way around it until subclipse 1.7.0 comes out and
3) in the meantime I should always do these commits when they appear.
Do I have that right? And when is the 1.7.0 release forecast for?
And thanks for the advice on the trunk replacement.
Steve
Mark Phippard wrote:
> On Thu, Feb 11, 2010 at 10:11 AM, Steve Cohen <scohen_at_javactivity.org> wrote:
>> I have two questions about merging, one small and one large and the
>> answer to the second might also solve the first.
>>
>> The first problem is that after a merge from a branch back to HEAD,
>> there are a few files that ALWAYS show up in Team->Synchronize with
>> Repository as needing to be committed even though there have not been
>> changes to these files in months. Checking them in does no good, the
>> next merge I do will bring them back as needing to be checked in again.
>>
>> I suspect some svn property is causing this but I don't know what it
>> might be. Can you tell me?
>
> This is caused by having explicit subtree mergeinfo. When you perform
> a merge, all of your paths that contain the svn:mergeinfo property
> will be updated to reflect the revisions you merged.
>
> See this blog post:
>
> http://blogs.open.collab.net/svn/2009/11/where-did-that-mergeinfo-come-from.html
>
>
>> The second question is this. On another branch, I have been working on
>> a wholesale change of the entire system. Basically this new system will
>> use Maven, and the previous one did not. Code has been moved between
>> projects, or into new directory structures and there are new projects
>> created, old projects deleted, etc. Eventually, I am going to want this
>> branch to BECOME the _trunk, replacing anything that is now in the
>> trunk. I will want the no-longer used projects to be gone from the
>> trunk, the new projects added to the trunk, and those projects that have
>> been changed to still exist. The project structure is basically
>>
>> _trunk
>> projectA
>> projectB
>> projectC
>>
>> _branches
>> BRANCH_NEW
>> projectA
>> projectC
>> projectD
>> projectE
>>
>> and I will want it to be this
>>
>> _trunk
>> projectA
>> projectC
>> projectD
>> projectE
>>
>> Oh, yes, and I'd also like history to be maintained.
>>
>> What type of merge is the best way to achieve this? Or is there a
>> better way? And if I do it will the first small problem be solved?
>
> If Branch contains the contents you want, then I would not do a merge.
> I would delete trunk and then copy or move BRANCH_NEW so that it is
> called trunk. This can be done from the SVN Repositories view.
>
> We even did this years ago in Subclipse. When Eclipse 3.0 came out
> the Team API drastically changed and so we had to rewrite huge parts
> of Subclipse. Eventually that branch just became trunk. Here are the
> commits:
>
> First we created branches for trunk to preserve it. We also deleted
> trunk at the same time:
>
> http://subclipse.tigris.org/source/browse/subclipse?view=rev&revision=1322
>
> Then we recreated trunk by copying the Eclipse 3.0 branch.
>
> http://subclipse.tigris.org/source/browse/subclipse?view=rev&revision=1324
>
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2446897
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-02-11 22:25:41 CET