I did post to the users mailing list as requested and added a few more
details which resulted from various tests I have now done.
To answer your questions:
> > 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?
> > 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:
-1 /branches/2.1/[filename]:402-635 with a line through it
> 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.
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
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.
Regarding the slow speed of merging - well let's get the merge working
Thanks for all your help on this!
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-12 17:39:05 CEST