Stephen Armstrong wrote:
> Ryan Schmidt wrote:
>> On Jan 30, 2008, at 15:58, Stephen Armstrong wrote:
>>
>>> Our company uses developer branches much like the practice of
>>> Feature Branches described in the svn book
>>> (http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature).
>>> We've been noticing that merges are taking quite a while on some
>>> larger projects (15 - 20 min), regardless of how many changes were
>>> made.
>>
>> That seems to be a long time, but what is "larger"? How many files
>> and directories are we talking about? How much space on disk does a
>> working copy consume?
> When I checked out (and exported, so the .svn folders aren't
> interfering) trunk, it's 360 files, 58 folders, totaling 18.3MB.
>>> Because of other practices, we've always got a working copy of our
>>> branch, and of the trunk on disk, but we can't do the merge with a
>>> command such as:
>>>
>>> merge ./trunk ./branch ./trunk
>>>
>>> It seems that when specifying a working copy for the merge, it only
>>> uses it like an anchor, to get the URL for the repo. Is there a way
>>> we can do the merge client-side? Some kind of offline-merge?
>> I don't think you can use local working copies to do the merge.
> Are there known practices that will significantly increase a merge
> time? I'm grasping at straws thinking maybe there's alot of properties
> set on files in that project, and so all the PROPGET requests to the
> server are causing extra slow-down. Also, as comparison, another
> project that is 342 files, 85 folders, but only 1.5MB merges very
> quickly, so it seems like number of files isn't the cause, but
> possibly sheer size could be.
I'm replying to my own message to present more information.
I think the slow-down is caused by how 'long' the branch has existed.
The two people working on this project have both had their developer
branches around for quite a while. A third user created a new branch and
did a merge, and it was almost instant. So the slowness must be caused
by merge's tracing back up the ancestry to where the branch was
originally created. Even though a.txt is the only file changed _since
the last merge_, hundreds of other files have been changed since branch
creation, so merge compares them to trunk, and finds them identical.
Am I right in how merge works? When it looks for ancestry, if the file
hasn't changed since branch creation, it doesn't compare it? So what
we're seeing here is the unneeded download and compare of many identical
files? (Unneeded for my case, but it makes sense for subversion to be
doing it)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-31 19:36:37 CET