Merging Branch to Trunk takes 20 min for one change
DCarson
branches and merging.
I am using Tortoise SVN 1.6.5 although at the time of original
creation of SVN we were using 1.5.3 I believe.
Our problem is that merging a single change from branch to trunk takes
15-20 minutes in some cases.
In other cases it only requries a few seconds. The same case occurs
for all developers who have attempted to merge, using diff systems
higher bandwith, etc.
Is this simply because some files have a long history? Our project is
less than a year old, although there have been many revisions to some
files.
Or is this due to something we have done incorrectly?
I have searched and seen many posts regarding slow merging but they
seem to apply to system issues, which I do not think is our problem.
So, any light you can shed would be helpful.
Thank you
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2404435
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Stefan Küng
> First, let me say I am relatively new to SVN, especially to using
> branches and merging.
>
> I am using Tortoise SVN 1.6.5 although at the time of original
> creation of SVN we were using 1.5.3 I believe.
Upgrade your server to 1.6.x. And then do a dump/load cycle on the
repository.
And you should not remove the svn:mergeinfo properties - if you remove
those before a commit, subseqent merges will take longer and longer.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2404605
Dadeo
Code. I believe Google currently uses version 1.6.
Afaik all merges have been done using Tortoise SVN via Windows
Interface (right click,select Merge). However some may have been done
prior to version 1.5. But I don't think we have ever removed merginfo
properties.
In the last merge I tried (from branch to trunk), many files appeared
as modified, although diff shows no changes between the files. I read
another post here about this issue which was related to version 1.5?
Is that correct? I have not committed that merge to trunk yet. Should
I? Or should I revert it and do the dump/load cycle first and then
redo the merge?
Will a dump/load cycle correct all the above problems? And how do I
ensure no one is removing mergeinfo properties?
Thanks again for all the assistance.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405307
Dadeo
files that say they are modified, yet show no diff, i see a merge from
a branch that has since been renamed. Would that cause them to show
as modified? Could that also be the reason the merge is so slow?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405628
Stefan Küng
> Stefan - thanks for the info. I should have said we are using Google
> Code. I believe Google currently uses version 1.6.
>
> Afaik all merges have been done using Tortoise SVN via Windows
> Interface (right click,select Merge). However some may have been done
> prior to version 1.5. But I don't think we have ever removed merginfo
> properties.
Maybe you haven't, but maybe someone else on your team has?
> In the last merge I tried (from branch to trunk), many files appeared
> as modified, although diff shows no changes between the files. I read
> another post here about this issue which was related to version 1.5?
> Is that correct? I have not committed that merge to trunk yet. Should
> I? Or should I revert it and do the dump/load cycle first and then
> redo the merge?
how do you do the diff on those files? TSVN should show you a diff of
the properties if those have changed.
You can use the check-for-modifications dialog to check what exactly has
changed: right-click on the column header, then select "Text status" and
"Property status" to show those columns. If only the properties have
changed, you would see a status of "normal" in the "text status" column
but a "modified" on the "property status" column.
> Will a dump/load cycle correct all the above problems? And how do I
> ensure no one is removing mergeinfo properties?
I'm not sure if a dump/load will fix missing mergeinfos, but a dump/load
will improve the repository and make it access faster with 1.6 - an 1.6
server can still access 1.5 repositories, but it can do so faster with
the new format.
But if you're using Google code, you can't do a dump/load cycle since
you don't have direct access to the repo.
and unfortunately, there's no way to ensure that mergeinfo props are not
removed.
There's also a thread about the same issue on the svn mailing list:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405612
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405654
Dadeo
the project.
> how do you do the diff on those files?
I used right-click - DIff and also Diff with Previous version.
Neither show any changes to the file. When I navigate to previous and
next Difference, it just goes to the top and bottom of the file.
> If only the properties have changed, you would see a status of "normal" in the "text status" column
> but a "modified" on the "property status" column.
Yes, Properties show as modified, text shows as normal on the modified
files that do not show any diff
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
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
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”
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?
> There's also a thread about the same issue on the svn mailing list:http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessa...
>
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?
>
I did try to find these in the Help file, but perhaps the terminology
is different? I am happy to research and learn if you can just point
me in the right direction.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405678
Dadeo
1. I committed one of the files from my merge to /trunk. It was one
of the files showing modified properties.
2. I then modified that same file in /branch with a new modifiction
and committed the change to branch.
3. I tried to merge that changed file to /trunk but it showed as a
conflict, which it should not, since the file in /trunk has not been
modified.
I am at a loss what to do. Our project is grinding to a halt as we
are unable to merge changes from branch to trunk. Our branch has many
changes in various states of development, some ready to merge to
trunk, some not., some which will 'break' areas of the project until
they are completed. Recommitting all these directly to /trunk or to a
new branch if we have to create one will be considerable work. But if
that is what we must do, now is better than later :).
Since I do not understand where the problem lies I am not sure what
solution will work.
What would you recommend to resolve this issue?
1. Create a new branch and recommit all changes
2. Do not use branch/merge in our project but commit all changes to /
trunk
3. Delete and recreate the entire Project repository
None of these are ideal, and I am not even convinced option 1 will
work. But we have to do something. If you need to look at the
repository, the link is http://code.google.com/p/amped/source/browse/
I realize it is not your job to fix our repository. I am only hoping
you can tell us why branching and merging is not working for us and
how we should do it so it does work.
The issue of the speed of the merge is now secondary and can be dealt
with later (unless is is connected). Our current problem is the
inability to merge from branch to /trunk successfully.
Thanks for any help you can provide. And I apologize for creating two
issues in one post. I should have started a separate one about our
merging problem separate from the speed issue.
Doug
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405887
Stefan Küng
> 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”
So the mergeinfo properties are still there.
> 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?
That shouldn't be a problem.
>> There's also a thread about the same issue on the svn mailing list:http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessa...
>>
> 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
Just update your working copy (use the "update" command in TSVN).
> 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
That's what an update does - it updates the working copy to the HEAD
revision.
> mergeinfo" How do I get all my mergeinfo at the tree root as
> recommended in that post?
When merging, it is recommended that you do all merges always from the
root of your working copy, not just from a subfolder or even a single
file. While the latter is possible and works fine, it will make
subsequent merges slower.
> I did try to find these in the Help file, but perhaps the terminology
> is different? I am happy to research and learn if you can just point
> me in the right direction.
Maybe you should ask on the code hosting group:
http://groups.google.com/group/google-code-hosting?pli=1
Google code has its own implementation of the svn repository, using
their bigtable system. So it might be an issue with that. Even if it's
not, the guys who run the Google code hosting (and implemented it) are
svn developers (some former, some are still active) so they know a *lot*
about the internals of Subversion.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2405901
Dadeo
that the problem is not anything we have done in the restructuring.
I will contact Google regarding our merging problems as you suggested.
Regarding the speed issue:
We always update before merging. So that is not the problem.
> When merging, it is recommended that you do all merges always from the
> root of your working copy, not just from a subfolder or even a single
> file. While the latter is possible and works fine, it will make
> subsequent merges slower.
>
To make sure I undestand you correctly. You are saying that I always
should select the root in my WC when merging. Then I select the
revisions that apply only to the branch and folder I wish to merge. Is
that what you mean?
If so, then why do merges from our apps folders only take a few
seconds while merges from our /skin folder take 20 minutes?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406066
Stefan Küng
> Thanks Stefan, you have been very helpful. It is reassuring to know
> that the problem is not anything we have done in the restructuring.
>
> I will contact Google regarding our merging problems as you suggested.
>
> Regarding the speed issue:
>
> We always update before merging. So that is not the problem.
>
>> When merging, it is recommended that you do all merges always from the
>> root of your working copy, not just from a subfolder or even a single
>> file. While the latter is possible and works fine, it will make
>> subsequent merges slower.
>>
> To make sure I undestand you correctly. You are saying that I always
> should select the root in my WC when merging. Then I select the
> revisions that apply only to the branch and folder I wish to merge. Is
> that what you mean?
>
> If so, then why do merges from our apps folders only take a few
> seconds while merges from our /skin folder take 20 minutes?
Sorry, it's not really that you should always merge from the root of the
wc. The point is that you should always merge from the same folder of
your wc - and that's usually the wc root.
If however you always merge from your /skin folder, then you should keep
doing that. The mergeinfo properties are set according to the folder
you're merging from, so if you always do it from the same folder, those
properties help speed up the merging a lot. However if you merge from
many different folders, those properties can't help you a lot to speed
up the process - they still help, but the merging has to ask the
repository for every folder that hasn't the full mergeinfo properties.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406122
Dadeo
"If however you always merge from your /skin folder, then you should
keep doing that."
I did contact Google and they said it is not a problem with Google
Code Project Hosting and suggested I contact you! LOL It's good I
still have my sense of humour! BTW we do not use Mercurial although
they suggested, as a last resort, we should "hand-assemble a new tree
that has all the changes you want (manually mixed together), and then
switch to mercurial (starting with a clean history)"
Obviously, I am hoping for a better solution that would require less
work. So, I am just asking for your expert opinion on how I should
repair our project. I tried creating a new branch, committed some of
my changes to it, and merging that revision to /trunk, but it resulted
in the same problem where all versioned files show modified
properties.
Is the only solution to delete our Repository and create a new one?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406309
Stefan Küng
> Thanks for clarifying that Stefan:
> "If however you always merge from your /skin folder, then you should
> keep doing that."
> I would love to keep doing that, if I could get it to work!!!
>
> I did contact Google and they said it is not a problem with Google
> Code Project Hosting and suggested I contact you! LOL It's good I
> still have my sense of humour! BTW we do not use Mercurial although
> they suggested, as a last resort, we should "hand-assemble a new tree
> that has all the changes you want (manually mixed together), and then
> switch to mercurial (starting with a clean history)"
I wouldn't have expected such an answer from Ben :)
Anyway, he told you to ask on the Subversion mailing list, not on the
TSVN mailing list because the svn mailing list is where the svn core
developers answer questions. They know a lot more about the internals of
the svn library than I do.
> Obviously, I am hoping for a better solution that would require less
> work. So, I am just asking for your expert opinion on how I should
> repair our project. I tried creating a new branch, committed some of
> my changes to it, and merging that revision to /trunk, but it resulted
> in the same problem where all versioned files show modified
> properties.
>
> Is the only solution to delete our Repository and create a new one?
I've checked out amped trunk and the 3.1 branch. Then I did a merge:
Merging revisions 710-742 of
http://amped.googlecode.com/svn/branches/3.1/skin into
D:\Development\SVN\SVNTests\amped\skin, respecting ancestry
with D:\Development\SVN\SVNTests\amped being a wc of the amped trunk.
The merge took 3 minutes and 19 seconds - nowhere near the 20 minutes
you get.
I would therefore suspect either a problem with your internet connection
or maybe a broken working copy (which could be fixed with a fresh
checkout). Also, there might be a virus scanner which slows down the
data transfer too much.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406311
Dadeo
confirm that the merge did not show modified properties on all
versioned files? If so, that is very enouraging. At least I know it
can work.
> Anyway, [Ben] told you to ask on the Subversion mailing list, not on the
> TSVN mailing list because the svn mailing list is where the svn core
> developers answer questions. They know a lot more about the internals of
> the svn library than I do.
Sorry, I did not realize the difference.
I did a fresh checkout and tested before I initially reported the
problem to you. I also had two other developers test the merge and
they had the same problems I did, so I concluded it was not a problem
with my system/internet. However, I did not check what anti-virus
they were using.
I duplicated your test exactly as you described. I assume the depth
was working copy. I disabled my anti-virus (Nod32) before the new
checkout and merge.
The slow part of the merge is the first part - averaging about 750
Bytes/s. Once the merged starts sending content (at about 1096 kBytes
transferred) it transfers at about 33 Kbytes/s. My internet speed is
only 256kb/s. But the other developers tried at much higher speeds
with the same results.
The results of duplicating your test were odd. I received tree
conflicts. All versioned files are still marked as modified
properties. And the merge still took almost 20 minutes.
I will try to post to your mailing list as requested. But if you
could confirm that you did not get the modified properties, that would
be great.
Thanks again for your wonderful support
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406343
Bob Archer
> 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
Doug Carson
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?
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.
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.
Regarding the slow speed of merging - well let's get the merge working
first :).
Thanks for all your help on this!
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406704
Bob Archer
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
Stefan Küng
> Wow, I did not expect you to do that for me! Thank you. Can you
> confirm that the merge did not show modified properties on all
> versioned files? If so, that is very enouraging. At least I know it
> can work.
>
>> Anyway, [Ben] told you to ask on the Subversion mailing list, not on the
>> TSVN mailing list because the svn mailing list is where the svn core
>> developers answer questions. They know a lot more about the internals of
>> the svn library than I do.
>
> Sorry, I did not realize the difference.
>
> I did a fresh checkout and tested before I initially reported the
> problem to you. I also had two other developers test the merge and
> they had the same problems I did, so I concluded it was not a problem
> with my system/internet. However, I did not check what anti-virus
> they were using.
>
> I duplicated your test exactly as you described. I assume the depth
> was working copy. I disabled my anti-virus (Nod32) before the new
> checkout and merge.
Ahem: Nod32 saves you from yourself and doesn't disable itself properly,
even if you ask it to. From what I've seen with that 'thing' is that it
just won't stop 'protecting' you.
I once had to completely uninstall that crap to get a connection working
properly. Admitted, it was about two years ago and I'm sure it has new
versions since then, but that was enough for me to get rid of it for good.
> The slow part of the merge is the first part - averaging about 750
> Bytes/s. Once the merged starts sending content (at about 1096 kBytes
> transferred) it transfers at about 33 Kbytes/s. My internet speed is
> only 256kb/s. But the other developers tried at much higher speeds
> with the same results.
The 'slow' part as you describe it is the part where svn asks the
repository for the required merge info. Since that info is sent in small
data packets (usually only a few revision data for every request the
client sends), the number of bytes/s is very low. What takes most of the
time is the establishing of connections to the repository (and there are
a lot of those).
> The results of duplicating your test were odd. I received tree
> conflicts. All versioned files are still marked as modified
> properties. And the merge still took almost 20 minutes.
Yes, I also got a lot of files marked as modified and even three tree
conflicts. But all those files that were marked as modified had their
svn:mergeinfo property modified, not their contents.
You could also try a nightly build. Since I'm using always the latest
one from trunk, it might be that there are improvements in the svn
library which are not yet in a release (btw: 1.6.6 is planned for the
end of this week).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406749
Doug Carson
1. Updated (added) the mergeinfo properties manually to trunk/skin in
WC
2. Merged one revision from /branches/3.1/skin to /trunk/skin (to get
the child properties to elide)
3. Verified that mergeinfo properties were elided on all child nodes
(subfolders and files)
4. Committed that merge to /trunk
5. Merged range of revisions that were ready to merge from branches/
3.1 to /trunk
And the wonderful news is that it worked! I successfully merged all
my latest revisions.
So you have one happy camper here!
> To really understand this I recommend you read this article:
> http://www.open.collab.net/community/subversion/articles/merge-info.html
Yes, I did already read that page and even though I have never used
command line, and a lot of it was over my head, it was still extremely
useful and helped me grasp the logic of the way merge tracking/
mergeinfo works
> 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&dsMessa...
That is an excellent post. It should be added to your FAQ as there
seems to be a lot of questions about it.
>
> 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.
>
Now that is a very useful tip which I could not find in the Help File
regarding Merge Reintegrate. In fact, there is very little info on
Record only. To be certain I understand you clearly, is this what I
should do?
1. Merge Reintegrate a feature branch to Trunk
2. On WC of Branch, merge from /trunk - record only
3. Choose the revision # of the merge reintegrate
Does it matter what type of merge I choose? Should I merge using the
branch folder or from root or does it matter?
BTW, I noticed some people use http. We have been using https. Is
there any difference in merge performance between them?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406806
Bob Archer
(The help basically tells you to delete the branch after you reintegrate.)
Don't forget step 0, merge any trunk changes into your feature branch first. But after than yes, you've got the basic steps.
To answer your question:
You should merge into the branch that you just reintegrated from. What you want to happen is let's assume you just reintegrated from /branches/3.1 to /trunk/skin and you commit your merge to trunk and that commit is r1234. You now right click on your /branches/3.1 WC and choose merge. Select regular merge and select /trunk/silk from the repo browser. Specify r1234 and check tell it record only.
What you should see is a mergeinfo record added to /branches/3.1 of something like /trunk/silk r1234 ... If that is correct commit it. You have basically told svn that /branches/3.1 includes all the changes in rev 1234 of /trunk/silk so the next time you do a merge from trunk, it won't include those revs.
Of course, your use case could be that you are NOT merging from trunk into your branch. If this is the case then you won't be doing reintegration's anyway. That is our basic use case. We dev from trunk and create a release branch. So, we never merge from trunk to our branches, only from the branches back into trunk assuming we fixed and issue on the release branch and want it to go back to trunk.
> BTW, I noticed some people use http. We have been using https. Is
> there any difference in merge performance between them?
I don't think it would make a big difference. But, if you are in a LAN you don't really need to use SSL.
One thing that was mentioned recently on the svn list was someone who has a merge that took an hour. He changed to the svn protocol and it took a few minutes. I think he found that he had HttpKeepAlives set to off which was adding ALOT of overhead to the merge since it makes alot of connections to the server.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406818
Doug Carson
I think I understand it much better now. The slow part is when SVN is
checking and updating the mergeinfo, which it seems to do on all the
files affected by the range of revisions.
I read a few posts about workarounds other users have tried. Some of
them just delete mergeinfo, but doesn't that disable Merge Tracking? I
like Merge Tracking!
Other users suggested using a record only reverse merge after creating
a branch. Not sure I understand how to do that yet! Or the
implications!
I also recall reading a post from Mark Phippard saying that getting
all your mergeinfo at root helps improve performance. However the way
our project is organized, I am almost always merging from a tbranches/
3.1/skin to /trunk/skin so I am not sure how to do that.
I can wait for 1.7 and hope it helps. But if you have any suggestions
or recommendations in the meantime, I would appreciate it. Especailly
since you are batting a thousand so far :)
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406832
Doug Carson
(The help basically tells you to delete the branch after you
reintegrate.) Yes it does! But we were keeping it as a tag release.
Probably not the correct way to do that either! So, in future we will
delete the branch after reintegrating. I will read up on the proper
way to create a tag release.
"Don't forget step 0, merge any trunk changes into your feature branch
first. But after than yes, you've got the basic steps."
Yes, I didn't mention step 0 because as you correctly surmised, we
don't merge from trunk to branch. We use a similar basic use case, we
do all development and fixes in branch and only merge to trunk when
approved. Trunk is our release source and once a release is done, we
create a tag/copy/snapshot of trunk. So normally we do not need
reintegrate, but our last release required major changes that would
have 'broken' the product if merged to /trunk while in development. So
we developed the full release in a feature branch and reintegrated
it. In case that happened again, I just wanted to be clear what
should be done. And your instructions were perfect.
"One thing that was mentioned recently on the svn list was someone who
has a merge that took an hour. He changed to the svn protocol and it
took a few minutes. I think he found that he had HttpKeepAlives set to
off which was adding ALOT of overhead to the merge since it makes alot
of connections to the server."
We are using Google Code Project Hosting. I am not running in a LAN
or Server environment, and I have never turned HttpKeepAlives off
afaik! Does that even apply in our case?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406973
Kurt Pruenner
> So normally we do not need reintegrate, but our last release required
> major changes that would have 'broken' the product if merged to
> /trunk while in development. So we developed the full release in a
> feature branch and reintegrated it. In case that happened again, I
> just wanted to be clear what should be done. And your instructions
> were perfect.
Ummm... if that's the case, i.e. if the code on the branch is what got
released - why not just throw out the trunk folder and copy the branch
to trunk? Takes approximately no time and makes sure all your released
code ends up where it should...
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2406987
Doug Carson
developers thought of that! It would have saved me tons of time! And
it results in a lot less mergeinfo!
I am happy to report that since following Bob's instructions I have
done several merges. A single change now takes about a minute. A
range with 13 diff revisons took about 5 minutes. Getting our
mergeinfo to elide correctly was a huge boost to our productivity!
So many, many thanks to you all!
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2407086