On Aug 18, 2010, at 11:24 AM, Ryan Schmidt wrote:
>
> On Aug 18, 2010, at 07:47, Lezz Giles wrote:
>
>> Imagine the following scenario:
>>
>> - trunk has several large files (> 20M) which are updated regularly. These files are +only+ changed on trunk.
>> - there are several branches, each of which updates from trunk at least once a week.
>>
>> The merge of the large files from trunk takes an excessive amount of time and creates new very large versions of files
>> that previously took up effectively no space at all, since they were cheap copies.
>
> Are you sure these are now taking up a lot of space? Are you using the latest Subversion and is your repository thoroughly upgraded? I thought the new "rep sharing" feature was supposed to make this a non-issue now. But I have not actually used it myself so maybe I misunderstand its purpose.
We aren't running the latest SVN on our server, though we will be moving to an upgraded system in the next day or so. With this feature, it looks like disk space won't be an issue moving forward.
However there is the secondary question of performance. Running 1.6.5, creating a brand new repo with a 20MB text file
on trunk, then creating a branch, adding a new version on trunk, and merging out to the branch takes a long time - I'm giving
up waiting for it after around 30 minutes, running on a six-month old MacBook Pro where top is showing svn taking up around
100% of a cpu. And this is for files where a quick review of the histories would show that the merge can be done as a simple
copy.
So my question remains - is it worthwhile analyzing the history of files involved in a merge and doing the copy where the
analysis shows that a copy is all that is required? Are there pitfalls that I'm going to find? I think the only difficult step is going
to be determining that the history of one file is a prefix of the complete history of the other file - in git terms, that fast-fowarding
is possible.
Lezz
Received on 2010-08-18 19:14:59 CEST