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