Hi Adam,
I have to admit that I think you are on the completely wrong track here.
You are using svn as a distribution channel, and that's most certainly
not the purpose of the tool. Checking builds into svn is of course going
to increase the size of the working copy and the repository by gigabytes
on every release.
You have several different approaches to handle this, and I can give you
two of them here.
You can have a build script so each developer builds a new Qt on his own
machine. If one person updates the script on a new release (and this
should be in svn of course), then it's not going to take any time to
start the build on the developer machines. And they can just start a
build when they leave in the evening.
Another approach is to have pretty much the same setup as you have now.
But instead of putting /qtbuild in svn, you place it on an ssh server
and distribute with rsync.
Yet another approach is for the build guy to create a zip file with a
new /qtbuild. Then each developer can get the zip file, wipe the old
/qtbuild and unpack the new one.
I hope this helps.
Bo Thorsen.
Fionia Software - Qt experts for hire.
Den 21-09-2012 01:03, Adam Light skrev:
My company currently has a Subversion repository for Qt that looks
like this:
/qtbuild
/qt
/build
/macosx
/install
/macosx
/win32
/win64
The /qt directory contains a git checkout of qt.
The /install subdirectories contain the compiled frameworks/dlls for
both a debug and release build of qt.
The /build/macosx directory contains all of the object files generated
when compiling. These seem to be required to be able to step into qt
code using gdb.
When a new version of Qt is released, I checkout that tag in the /qt
directory and then rebuild Qt using certain configuration settings. I
then commit all changes (the new frameworks/dlls, object files, etc.)
to the Subversion repository. Other developers at my company can then
update their Subversion checkouts so they have the new version of Qt.
This works pretty well except that it requires checking a lot of
binary files into Subversion, and both committing the files and
checking them out is very slow. The size of the working copy is also
extremely large (this can be addressed partly by using Subversion's
sparse checkout feature). The repository on the server is also quite
large.
We use this process in part because some developers use
not-so-powerful machines (and/or Windows virtual machines) on which
compiling Qt can take multiple hours. Furthermore, as long as everyone
runs svn update when I build a new version of Qt, we know that we are
all using the same version and libraries.
But I wonder whether there is a better way to handle this. How do
other groups handle this? Using the binaries and/or SDK available for
download is not an option for us because we need different
configuration options and we sometimes need to patch Qt's source to
fix bugs that have not bee fixed in Qt's git repository.
Thanks for any ideas.
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
Bo Thorsen.
Fionia Software - Qt experts for hire.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
