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:
http://subversion.tigris.org/svn_1.6_releasenotes.html#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.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403186
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-03 12:43:44 CEST