Ryan Schmidt wrote:
> On Jan 31, 2008, at 12:36, Stephen Armstrong wrote:
>> 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)
> merge is just a diff and patch. Maybe you'd better show us the exact
> merge command you're typing...
The command we were using is:
svn merge trunk_at_HEAD branch_at_HEAD trunk
Now, according to ancestry, branch has had most of it's files modified
since it was created months ago. But since last time we ran this merge
(and so synced all files) we've only modified 1 file. It still takes a
while (apparently it's only 7 min or so. Not 15-20 as I was led to
believe), but as I've said, a new branch with the same amount of changes
seems to happen almost instantly. I would assume this is because the
diff uses ancestry to eliminate any that haven't been modified since
branch creation and diff those that have.
It looks like getting our users to delete their branch and recreate it
after merging all finished changes into trunk will solve the problem by
keeping all branches young.
---------------------------------------------------------------------
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 23:50:31 CET