RE: Merging Branch to Trunk takes 20 min for one change

> I cannot believe I neglected to tell you the most important info! I
> should have given you a history of what we haved done to our SVN: I
> apologize, I thought I had explained this better!
>
> 1. We never used branches until recently. Then we needed to create a
> feature branch – branches/2.1 which was an exact copy of /trunk at
> that time.
> 2. We did not commit any further changes to /trunk – we only worked on
> branches/2.1
> 3. When the feature - branches/2.1 was completed, we merged it to /
> trunk using Merge Reintegrate
> 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.

> 5. When we released the latest version, branches/3.0 was renamed to /
> tags/Release 3.0
> 6. As we started work on verison 3.1, we created a new branches/3.1
> which was an exact copy of /trunk

I noticed you didn't say if you merged branches/3.0 into trunk? So you copied /trunk to branches/3.1?

> 7. Next, we decided to add some new apps to SVN. Those were initally
> added separately from /trunk
> 8. However, we decided we wanted everything in /trunk and so we
> restructured /trunk to include new subfolders for the new apps. We
> also moved the existing files from /trunk to a subfolder /skin I
> believe this was done using Repo Browser.
> 9. Branches/3.1 was still using the old structure and Test Merges
> resulted in "skipped missing target" errors. So we restructured
> branches/3.1 to match the new /trunk structure.
> 10. Then I tried to merge a range of revisions from branches/3.1 to
> trunk/skin and that resulted in all versioned files showing as
> modified (Properties, text is normal except for those that have
> actually changed)
>
> 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?

> Of course, /branches/2.1 no longer exists - could that be our
> problem? Since every file now has it in the mergeinfo properties. If
> so, how do we correct this now?

Perhaps, but I don't think so. Basically that file knows that you merged from /branches/2.1 r402-635 into it. So it knows not to do that again. I assume it is updating all the files because each file already has merge info on it. This isn't really a problem. However, I would expect that the merge data would be elided.

What is the merge info on the /trunk/silk folder compared to that in the file itself? I assume it is difference considering no elision took place?

> Yes, that thread looks very similar to our problem. But I don't really
> understand the answer :). How do we "run svn up before you merge". And
> how do I have my "working copy at a single revision, and perhaps even
> at HEAD"? And how do I "check your working copy for subtree
> mergeinfo" How do I get all my mergeinfo at the tree root as
> recommended in that post?

svn up is the command line equivalent to right clicking on your working copy in TSVN and selecting "SVN Update". The common wisdom is to make sure you have no local changes in the target WC and that it is fully uptodate.

BOb

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406676

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-12 16:25:13 CEST