Thoughts on policy for storing things like JREs, 3rd party l
![](http://jazz.net/_images/myphoto/2ab6feb4c14585310ed716b1bc3d3a3d.jpg)
One of the projects we will be using RTC for contains a fairly large
code base (400MB). Included in this are several binary files from, for
example, a JRE that is included in the product, and 3rd party libraries
that are used by the product. I suspect they comprise 1/3 to 1/2 of the
size of the code base.
Arguments for including these in the repository are:
- Everything needed to build the product by developers is included in
the SCM repository
- When builds are done, the snapshot will include the specific levels of
everything, including the imbedded JRE, 3rd party libraries, etc.
Arguments against:
- The formal build process will take longer because the binary "stuff"
needs to be extracted with the source every time a build is done. If
these are externalized, they can be "cached" in the build environment.
- Increase the storage space used by the SCM. And since these are binary
files, I imagine replacement of a JRE for example, will add up over
time. And, there's no way to remove things once added to RTC.
I'm curious how others deal with this.
Brian
code base (400MB). Included in this are several binary files from, for
example, a JRE that is included in the product, and 3rd party libraries
that are used by the product. I suspect they comprise 1/3 to 1/2 of the
size of the code base.
Arguments for including these in the repository are:
- Everything needed to build the product by developers is included in
the SCM repository
- When builds are done, the snapshot will include the specific levels of
everything, including the imbedded JRE, 3rd party libraries, etc.
Arguments against:
- The formal build process will take longer because the binary "stuff"
needs to be extracted with the source every time a build is done. If
these are externalized, they can be "cached" in the build environment.
- Increase the storage space used by the SCM. And since these are binary
files, I imagine replacement of a JRE for example, will add up over
time. And, there's no way to remove things once added to RTC.
I'm curious how others deal with this.
Brian
One answer
![](http://jazz.net/_images/myphoto/2ab6feb4c14585310ed716b1bc3d3a3d.jpg)
Unless you really are disk challenged, putting your external projects
under source control is always best. Caching those projects for more
efficient builds are fine ... you don't always have to retrieve them
from the source control system to do a build. But you want to be able
to retrieve them from source control if you want/need to.
Cheers,
Geoff
Brian Gillan wrote:
under source control is always best. Caching those projects for more
efficient builds are fine ... you don't always have to retrieve them
from the source control system to do a build. But you want to be able
to retrieve them from source control if you want/need to.
Cheers,
Geoff
Brian Gillan wrote:
One of the projects we will be using RTC for contains a fairly large
code base (400MB). Included in this are several binary files from, for
example, a JRE that is included in the product, and 3rd party libraries
that are used by the product. I suspect they comprise 1/3 to 1/2 of the
size of the code base.
Arguments for including these in the repository are:
- Everything needed to build the product by developers is included in
the SCM repository
- When builds are done, the snapshot will include the specific levels of
everything, including the imbedded JRE, 3rd party libraries, etc.
Arguments against:
- The formal build process will take longer because the binary "stuff"
needs to be extracted with the source every time a build is done. If
these are externalized, they can be "cached" in the build environment.
- Increase the storage space used by the SCM. And since these are binary
files, I imagine replacement of a JRE for example, will add up over
time. And, there's no way to remove things once added to RTC.
I'm curious how others deal with this.
Brian