Helmut Zeisel wrote on Fri, Mar 02, 2012 at 10:28:16 +0100:
>
> Original-Nachricht
> > Datum: Thu, 1 Mar 2012 09:07:41 +0200
> > Von: Daniel Shahaf
>
> > Representation sharing works only on complete files. (If two files are
> > not byte-for-byte identical, it never kicks in.)
Original-Nachricht
> Datum: Thu, 1 Mar 2012 09:07:41 +0200
> Von: Daniel Shahaf
> Representation sharing works only on complete files. (If two files are
> not byte-for-byte identical, it never kicks in.) What you see would be
> the xdelta binary-diff algorithm being efficient
Helmut Zeisel wrote on Wed, Feb 29, 2012 at 10:41:13 +0100:
> My interpretation of this is that "representation-sharing" works well
> enough for compiled C++ code, i.e. if I change 2% of source code and
> commit the changed objects and libs, then typically a comparable
> amount (+/- 2%) of the obje
> Datum: Tue, 28 Feb 2012 13:43:05 +0100
> Von: Stephen Butler
> > Acutually this "representation-sharing" was my question. How good does
> it work for compiled C++ code? How much does the repository typically grow?
> It's best to write a simple script that loads various versions of your
> own f
Am 28.02.2012 14:42, schrieb Helmut Zeisel:
BTW: Another approach is to use a build server that e.g. runs
nightly and stores the results on a network share.
This does not work in our situation because for some components we do
not want to use the latest but some stable older version.
We have
> Datum: Tue, 28 Feb 2012 14:06:14 +0100
> Von: Ulrich Eckhardt
> An: users@subversion.apache.org
> Betreff: Re: Subversion for object code
> > I know that subversion was not invented for that purpose
>
> I tend to disagree a bit, Subversion was intended to version
On Tue, Feb 28, 2012 at 4:47 AM, Stephen Butler wrote:
> But it also has disadvantages:
>
> - Runaway repository growth. Object files and .jar files don't compress
> as well as text. If you bust a hard limit for your repository disk space,
> your IT service provider might force you to pay a dras
Am 28.02.2012 11:08, schrieb Helmut Zeisel:
Our software products use different components, where many base
components are used in different products. It is not necessary that
all developpers compile these componentens themselves, that is, these
components are distributed binary (as object files
On Feb 28, 2012, at 12:35 , Helmut Zeisel wrote:
[...]
>> There's a quick summary of binary-file handling here:
>>
>> http://svnbook.red-bean.com/en/1.7/svn.forcvs.binary-and-trans.html
>>
>> On the server side, Subversion stores files using a binary diff algorithm,
>> and has a "representati
On Tue, Feb 28, 2012 at 6:35 AM, Helmut Zeisel wrote:
> > Datum: Tue, 28 Feb 2012 11:47:43 +0100
> > Von: Stephen Butler
>
> Thank you for the quick answer.
>
> > But it also has disadvantages:
> >
> > - Runaway repository growth. Object files and .jar files don't compress
> > as well as text.
> Datum: Tue, 28 Feb 2012 11:47:43 +0100
> Von: Stephen Butler
Thank you for the quick answer.
> But it also has disadvantages:
>
> - Runaway repository growth. Object files and .jar files don't compress
> as well as text. If you bust a hard limit for your repository disk space,
> your IT se
On Feb 28, 2012, at 11:08 , Helmut Zeisel wrote:
> Our software products use different components, where many base components
> are used in different products. It is not necessary that all developpers
> compile these componentens themselves, that is, these components are
> distributed binary (
Our software products use different components, where many base components are
used in different products. It is not necessary that all developpers compile
these componentens themselves, that is, these components are distributed binary
(as object files or libraries).
To make the distribution of
13 matches
Mail list logo
