> > > 4. Then we renamed branches/2.1 to branches/3.0
> > Opps... I'm not sure if this will create a problem. It might. But,
> you probably should have created a new branch by copying trunk. It
> would have been cleaner.
> >
> Yes, we should have. Hindsight is wonderful! However, I have since
> tried creating a new branch, committing some revisions to it and
> merging it to trunk - same results!
>
> > I noticed you didn't say if you merged branches/3.0 into trunk?
>
> We did merge branches/3.0 to /trunk when it was named branches/2.1
> All we did after it was merged was rename it. Should we merge it even
> though there were no further changes or commits? It was subsequently
> renamed tags/Release 3.0. That branch 2.1 could have been deleted
> but we decided to keep it as a release tag - a snapshot of SVN at the
> time of release.
> >
> > So you copied /trunk to branches/3.1?
> Yes,.
> >
> > > When I look at merge properties for the files in trunk/skin that
> show
> > > as modified in my last merge (not yet committed to repository) they
> > > show: “s v n : m e r g e i n f o T
> /branches/2.1/common.dialog.xml:402-635/
> > > branches/3.1/skin/common.dialog.xml:707-730”
> >
> > Huh? Did you merge the whole folder or just that one file? Or are you
> saying that was a property on that file?
>
> I merged a range of revisions. I also tried merging only one
> revision. I get the same results - about 200+ files show modified
> properties. The above file was just an example. All the modified
> properties files look the same.
>
> When I check Diff, or Diff with Prev Version, then press escape to see
> the properties, I see:
> Working Base:
> -1 /branches/2.1/[filename]:402-635 with a line through it
> Working Copy:
> +1 /branches/2.1/[filename]:402-635
> +2 /branches/3.1/skin/[filename]:711
> >
> > What is the merge info on the /trunk/skin folder compared to that in
> the file itself? I assume it is difference considering no elision took
> place?
> >
> I think you may have hit on something there Bob. The mergeinfo
> properties on /trunk is the same as the file: /branches/2.1:402-635,
> but when I checked trunk/skin the mergeinfo properties on that folder
> are empty. That makes sense now that you point it out. Because the
> merge reintegrate I did was to trunk. The /skin folder was created
> after, so does not have mergeinfo properties. The only successful
> merge we have managed so far, was the merge reintegrate of branches/
> 2.1. I have not committed any of the merge tests I have tried.
This may be the problem. Since there is no mergeinfo on /trunk/skin and there is mergeinfo on child items then svn will apply the mergeinfo to all of the child items that already contain merginfo. Since the merge info on the children will not match the merge info on the /trunk/skin folder then no elision takes place either.
> All the folders and files within /skin have the same mergeinfo
> properties as above: /branches/2.1/[name]:402-635. Only the /skin
> folder itself is empty. Should I simply revert all the files and
> folders except the /skin folder and the files that have actually
> changed?
> Could that alone cause it to try to modify the mergeinfo properties on
> all the folders/files? If so, what is the easiest/best way to solve
> this? I cannot grasp why it is trying to add the merge to the
> mergeinfo properties of files that have not changed, and already have
> the correct mergeinfo.
You may want to manually add that merge info that occurs on all the files to your /trunk/skin folder then attempt the merge. If I am understanding you correctly that will elide all of the mergeinfo on the child folders/files. Of course they will all show as modified properties, since the properties are removed and you need to commit them all. Once you commit them all then further commits should only add mergeinfo to the /trunk/skin folder.
Once you commit everything from your merge ensuring that all the merg info on the files has been elided, by adding the merge info to trunk/skin, you should no longer see all these mods on the child nodes in future merges.
To really understand this I recommend you read this article:
http://www.open.collab.net/community/subversion/articles/merge-info.html
Then on the svn list there was a recent topic about mergeinfo elision that really is clear that may help you understand what is happening here:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2401813
> Regarding the slow speed of merging - well let's get the merge working
> first :).
Agreed.
>
> Thanks for all your help on this!
>
Also, make sure after you reintegrate a branch you either delete it or do a --record-only merge on the branch from trunk of the rev that was created when you committed the merge into trunk.
Hth,
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406719
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-12 18:21:50 CEST