> 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.
Received on 2012-10-30 07:00:16 CET