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.
---------------------------------------------------------------------
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 16:03:18 CET