> I don't think I did fully understand the interaction between your > build system and your devs, as normally build systems like Jenkins, > Hudson etc. run on a separate server fully automated and per default > just don't commit anything, therefore it's very unimportant if the > working copy they are working on is flagged as changed in any way or > not. So your build system is used on the devs machines and works on the > same working copy as your devs work on that you get a problem with svn > status?
Maybe I called our system the wrong name. It is a homemade system, and here are some of the things that it does: 1) Each project is specified by a custom configuration file, which lists the source files to be compiled using different tools and sets up project-specific options. These configuration files are versioned and may contain conditional options based on target platform and other global options. 2) A developer chooses from a list which projects he wishes to work on, and edits a configuration file to indicate the platform he wishes to compile to, build flags and several other options. These local options are specified by locally modifying a versioned template file. The modified file is marked as ignored, no problems here. 3) The system checks out or updates all relevant code from the repository, including the selected projects and, depending on the local options, other projects on which they depend, or that depend on them. This is done with svn sparse directories, no problems either. 4) The system automatically generates platform- and option-dependent files, such as makefiles on Linux and Visual Studio project and solution files on Windows. These are marked as ignored. 5) Before compilation, several tools produce some automatically-generated source code, such as bindings between two programming languages. These files can be different depending on the target platform and other options, and there can be quite a lot of them. They should also be marked as ignored, but there is no naming pattern or specific location for them, which makes it hard to use global ignore patterns. Since the automatically-generated files are often #included in other non-automatic source files, the developer is free to choose the location and naming which are best for him. The names and locations are specified in the project configuration files. 6) After compilation, the system copies some files around, such as exported library headers and DLL dependencies of the generated executables. 7) The system also automatically generates installation scripts and executables for the end-users. Number 5 above is probably the most problematic case. We _could_ try to impose a specific location and naming pattern for those files, but this could affect headers used by client developers as well, so we would rather avoid that if possible. > Which subversion clients do you use? TortoiseSVN in Windows, just the command line in Unix.