Does the Subversion community have a recommend practice for controlling
"ongoing" binary builds in the repo?
My project currently stores, automatically, the binary build output
("globbed" together in a standard format in a .tar.gz file for each
"client" or "server" distribution on a per-platform--eg, mingw,
debian3--basis) in the same repo as our source code. This seems to work
quite well for us save for possibly one thing: it makes my repo directory
on my server grow to be very large (the tar balls run from 3MB to more the
Granted, we don't check in the binaries that we build all the time (we have
separate "trunk/src" and "dist/<platform>" directories to help this
separation), but still my repo server tends to balloon a bit
nonetheless...although this is not necessarily an issue, and checkouts
don't have to include our tarball build output in order to build a new tarball.
The big question I have: is there some other reason why we should not be
doing this, something we may not have stumbled upon yet?
Maybe we want builds stored in a different repo, or at least a different
place? We find it quite convenient to have it all in one spot.
An aside: we do control all of our "input"/vendor/external
libraries/binaries that we embed in our builds or at least depend upon to
run (thinks like OpenSSL, bzip2, PostgreSQL stuff) in our repo (in
trunk/dist/external), and we keep the source for these "external" projects
in a separate repo, and carefully control the copy from one repo to
another. (Let me know if this doesn't make sense, and I can provide a
more-detailed repo organization/layout.)
I realize that my question/message may not be that organized or coherent,
but I've waited too long to put forth this question to the community, and I
feel like I at least need to get the conversation going.
For what it's worth, I find this question related to the following note
that I just posted:
...but different enough that I thought it warranted a separate conversation
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Feb 19 02:27:41 2006