> -----Original Message-----
> From: Lezz Giles [mailto:lgiles_at_tripadvisor.com]
> Sent: 18 August 2010 18:14
> To: Ryan Schmidt
> Cc: users_at_subversion.apache.org
> Subject: Re: copy-merge in Subversion?
>
> 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
>
On a slight tangent, could this problem be side-stepped by using
svn:externals? Could you not have a separate path for your large files
and then external the head version into your trunk and peg revisions
into your branches?
I'm not sure about this but thought it might help. Can someone else
comment?
~ mark c
Received on 2010-08-19 08:28:00 CEST