On Thu, Aug 19, 2010 at 8:27 AM, Cooke, Mark <mark.cooke_at_siemens.com> wrote:
> > -----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?
>
That was my thought too, since "These files are +only+ changed on trunk".
Why do you need to branch those if they only change in trunk?
>
> I'm not sure about this but thought it might help. Can someone else
> comment?
>
> ~ mark c
>
Received on 2010-08-19 08:59:48 CEST