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

Re: understanding merge cost

From: Jan Hendrik <list.jan.hendrik_at_gmail.com>
Date: Mon, 11 Aug 2008 11:21:48 +0200

Concerning Re: understanding merge cost
Karl Fogel wrote on 10 Aug 2008, 10:41, at least in part:

> "Jan Hendrik" <list.jan.hendrik_at_gmail.com> writes:

> > Added up 150MB residing in the repository twice. Or is Subversion
> > aware that Steve's 50 origin in trunk and Slim's 100 origin in her
> > branch, making merge as cheap as svn copy is supposed to be? I
> > didn't find a word on this.
> http://subversion.tigris.org/issues/show_bug.cgi?id=2286
> Short answer: the storage is not shared in that case, and we agree
> it's a bug :-). Note that the issue has been started; see

Thanks, Karl. Seems we chose a bad occasion to branch for the
first time in years when branching for the development of a website
spin-off. Fortunately our numbers aren't as big as in the example
(yet), but nevertheless. (Back then [ver. .9 or 1.0] branching didn't
work when the EOL property was set, switching between
trunk/branch would amount for a complete checkout, so we never
used the feature again.)

Supposedly sharing storage accross branches will be quite difficult -
 Slim might modify Steve's added stuff before merging back into
trunk, and Steve or someone else might branch off for work on the
same files ...

Jan Hendrik
Freedom quote:

     Durch die Umkehrung der ökonomischen Regel
     "besser Subjektförderung statt Objektförderung"
     schwinden individuelle Freiheitsgrade in großer Zahl.
               -- Karen Horn, Die Besserwisser,
                        Frankfurter Allgemeine Zeitung, 12. März 2007

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-11 11:20:45 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.