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 or libraries). To
make the distribution of binaries easier, some developers started to
include also object files and libraries of the common base components
in the subversion repository.
I know that subversion was not invented for that purpose
I tend to disagree a bit, Subversion was intended to version non-textual
resources, too, and you are not doing something that is unsupported and
discouraged and left without support either.
but from our experience it seems that it actually works.
Yes, I'd even call it common use, even though it's not the majority.
My questions:
What kind of problems could occur if too many binaries are in the
subversion archive?
All files are binaries. The only issue here is the size they take,
because every change requires some storage in the repository. All other
issues like the history size and lookup time are probably negligible.
How good does subversion make diffs of object code?
SVN can save network bandwidth by only transmitting partial deltas of
any file. The problem is that e.g. compilers embed the compile date into
their object files, so compiling something twice will cause the output
to differ. If you then try to merge a change into that file, the part
representing the date will surely fail, and barring any human-readable
representation as for text files, you can't even resolve this conflict
manually.
What better options for sharing versions of object fils are
available?
You probably already know the typical trunk/branches/tags hierarchy.
Keep this hierarchy, but also keep it clean of object files, because
merging and diffing them just doesn't work. Instead, add a fourth folder
with release packages (e.g. bin). After making a tag, you commit a
compiled version of that tag including all necessary binaries to the bin
folder, so anyone can check out that folder and use the content without
compiling. This keeps the non-mergable binaries separate but alows
anyone that doesn't want to compile from scratch to just retrieve a
usable setup.
In no case would I check in binaries as part of regular development,
like in trunk or branches, as those changes just can't be merged. Also,
mixing changes made by the developer and changes derived from those
changes makes it harder to understand what exactly was done. In
practice, you can even commit changes that simply don't correlate if you
don't pay attention!
BTW: Another approach is to use a build server that e.g. runs nightly
and stores the results on a network share. It starts with "rm -rf ..."
and then checks out and builds each component from scratch. Components
that don't build or just build on one developer's machine don't pass
unnoticed that way. You could also mix the two, and only create release
packages from those "official" builds of the build server once they
passed the automated build an unit testing.
Good luck, I hope I gave you some good ideas!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein
sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen,
weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht
verantwortlich.
**************************************************************************************
