2012/1/13 Thorsten Schöning <tschoening_at_am-soft.de>:
> Guten Tag Les Mikesell,
> am Donnerstag, 12. Januar 2012 um 18:26 schrieben Sie:
>
>> We have a lot of component libraries that we
>> want to include in larger projects without recompiling each build
>> (i.e. we want to run known/tested instances) and have been including
>> the binaries in tags so the headers and shared libs are versioned
>> together.
>
> What's your problem at all? That you must version the same pre
> compiled libraries as a tag in each of your projects?
It is a combination of things. One is the long-ago decision to
combine a large number of projects in the same repository. The other
is that our QA group wants to test a binary library component
thoroughly, then make sure it is re-used instead of recompiled in each
project that uses it. Again, a decision made long ago for good
reasons at the time, but perhaps less important now that we have more
strictly-controlled build processes and environments.
> Are the
> libraries such big that you run out of space?
Not strictly speaking. That is we can deal with the overall disk
space and that requirement won't change by breaking things up.
However we are at a point where the time to complete a svnadmin
dump/load cycle is becoming impractical. I don't like a situation
where we can't perform maintenance.
>> It''s clearly the wrong thing to do, but it works.
>
> I don't think so, if it saves you time and guarantees the use of
> tested library versions, I would do the same. My in approach in my
> company is to use a separate Repository for all kinds of libraries,
> just version the source code and each developer has to build them on
> his machine on it's own. The IDE just references the built libraries.
> But we don't have that many libraries and whenever we can't build any
> library on our own, I version them pre compiled, too.
Unconstrained growth just seems philosophically wrong - and
unsustainable in the long run. It might be tolerable if each
component were in its own repository or if subversion had a reasonable
approach to removing objects, but I can't change those things.
> If one just copiess old library versions on updates etc. one can save
> a lot of disk space.
>
>> How
>> can you enforce getting exactly the right things in a parallel
>> repository that has only the headers and libs that will work the same
>> way for external references?
>
> Use tags and/or fixed revisions in your external definition.
Yes, we don't want to change the process of referencing known versions
via svn externals in the upper level projects, we just want the binary
objects and the necessary headers to be in a different repository. If
everything were java we would probably let maven handle the component
object versioning, but we have a mix of projects. We do use jenkins
for most build activity, so a custom plugin to tag the build results
might handle it without introducing mistakes.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2012-01-13 15:00:31 CET