> 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.
>
Externals can be pinned to a revision in your external repository. Although, it probably makes more sense to use well known paths so if you create a new repository you can duplicate the well known paths by just exporting your HEAD, deleting your repository, recreating it and importing the previous export. You can take this approach for internal and external binary components. Of course, if they are internal components you could include the source to them in your project and just build them with that project.
One issue we have is our legacy VB6 dll's that are built on every change. The dll's are put into source since most of our devs don't work on those binaries or can easily compile them. I have found that the bulk of our repo size is due to all these interim build versions. So, these are moved out of the primary source repository and put into a separate repo reference with externals. This repo can be replaced as it grows too big.
Now, source controlling external components is a judgement call. It might be better to just leave them in a public network folder and reference those locations in your source projects. Or, you can put them into source control, either the same repo or a separate one.
BOb
Received on 2012-01-13 16:43:05 CET