[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branch=>merge: additions + modifications twice in repository?

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 3 Oct 2009 11:42:56 +0100

On Sat, Oct 03, 2009 at 12:28:27PM +0200, Jan Hendrik wrote:
> Hi all out there,
> and I suppose this behaviour has not changed over the last few
> years and probably is not meant to change at all:
> Any addition or modification done and committed on a branch is
> physically added a second time to the repository once the branch
> is merged into trunk and committed, right?
> If development makes working on an isolated branch necessary
> that has priority of course. Yet if e.g. 200MB binaries (jpeg) are to
> be added on a branch and then would have to be added once again
> on trunk, thus doubling the space used in the repository, one
> begins to think. Particularly so in the case branching is not
> necessary for specific development reason, but merely to use
> some spare time as those resources are not to show up on
> production before several months.

You could enable rep-sharing:

Sharing multiple common representations (issue 2286, server)
   When using many branches and merging between them often, it is common
   to have files with similar lines of history which contain the exact
   same content. In the past, Subversion has stored these files as deltas
   against previous versions of the file. Subversion 1.6 will now use
   existing representations in the filesystem for duplicate storage.
   Depending on the size of the repository, and the degree of branching
   and merging, this can cause an up to 20% space reduction for Berkeley
   DB repositories and a 15% reduction for FSFS repositories.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-03 12:43:44 CEST

This is an archived mail posted to the Subversion Users mailing list.