On Mon, Jun 4, 2012 at 11:48 AM, Bram de Jong
<[email protected]> wrote:
>
> If you'd go back to my first email and substitute "repository" by
> "trunk" maybe my emails make more sense?
> Our apps don't need the full repositories, they just need the trunk/master.
> But still, the rest of my email(s) stay the same: we have many apps
> sitting in the same repository.
At least in subversion, if you put multiple projects in the same repo
you would normally put the project directories at the top level, each
with its own trunk/branches/tags fanout, so what you check out (and
what jenkins watches) is project/trunk - and you don't waste/duplicate
any space when each job does its own checkout. If you have a top
level trunk with multiple projects under that, things can get ugly.
But you should still be able to point to trunk/project for a build
job.
>> Is all of this somehow connected inseparably? Normally, builds would
>> be oriented towards versions of specific components and then
>> applications containing them, and the versions of different parts
>> would be allowed to advance at different rates.
>
> Yes, inseparable. Each of the repositories holds part of a huge
> codebase that is used in many of the applications all over the various
> repositories. Sure, we don't really like it this way, but we have no
> say in the matter, we can't change the way it is set up.
Everybody has components/libraries that are included in multiple
higher level applications. There are rare situations where you might
want to tie all of the trunk/HEAD versions together, but it is much
more common that you would want to tag specific versions of every
component so each has it's own development cycle that won't break the
dependent applications that build against tested/tagged component
releases, advancing those tags independently. So at some point in
your application level builds you must have some way to pick the
component versions. The one I am most familiar with is svn externals,
but you can do it other ways, and they don't have that much to do with
repository layouts. The catch is that the stock jenkins poller is
only going to know about one version control system per job.
> I definitely understand that -as Slide and you both say- this makes it
> rather hard (impossible?) to make easy distributed builds, but for now
> we're looking at a single computer with 2 VM's on it, that might help
> for now...
Your quick-fix here might be a network file share mounted/mapped into
all the slaves, but then you can only run one build at a time of
anything with dependencies. That approach does work for
seldom-changed or release-versioned components like boost library
versions, etc.
--
Les Mikesell
[email protected]
