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...
---------------------------------------------------------------------
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:39:56 CET