Hello all,
I have searched for this issue in several places, but none of the
feature requesters presented a scenario like mine, and the overall
conclusion was that the svn:ignore property was sufficient. However, I
stand by the opinion that a local .svnignore file is also necessary
(or some kind of _unversioned_ svn:localignore property). So, I'd like
to see some additional opinions on the matter. Details follow.
I have a build system that allows me to compile C/C++ code from a
single repository for a number of different platforms, including
several flavors of 32- and 64-bit Windows, Linux and MAC. During setup
and compilation, the system generates several local files, which are
different depending on the selected target platform, the selected
in-development projects, and some other local configurations. These
files are unversioned and should be ignored by the versioning tool.
Until some time ago, I used CVS as my versioning tool, and the
.cvsignore file worked perfectly. The build system knows what files
will be generated for the current configuration, so it just created
the .cvsignore file and filled it with the names of those files. Now,
I have migrated my repository to SVN, and I am having trouble with the
fact that the svn:ignore property is versioned. Since the list of
ignored files varies with the local configuration, it is usually
different for each developer in my team, and the source-code folders
are always marked by SVN as modified, which is kind of inconvenient.
The only solution I could think of (to be able to keep a somewhat
stable svn:ignore property) would be to populate the svn:ignore
property with every file that could ever be automatically generated by
the build system when operating in each and every local configuration
scenario. Even then, however, there is still some unnecessary hassle:
- For the property to be automatically updated, the build system would
have to simulate every possible configuration (lots of possibilities)
to update the svn:ignore property, which is a lot more work that
working only with the single, currently selected configuration.
- The system could get the current svn:ignore property and only add
new items to it based on the currently selected configuration, but
this may result in unnecessarily bloated svn:ignore properties over
time, since no-longer-generated files would never be removed from the
list.
- If the property is to be managed manually, then the developers must
remember to always update the svn:ignore property themselves every
time a new file is automatically generated or an old file ceases to be
generated. This is error-prone and requires every developer to know
about the internals of the build system.
The second option above is the strongest solution in my opinion,
but it is still more complex than a simple .svnignore file (or an
extra unversioned ignore property), and yet results in a not-as-good
behavior. So, I would like to know if anyone has a better idea, and/or
if anyone agrees that a local .svnignore file (or an extra unversioned
svn:ignore property) has a good use after all.
Thanks for the attention,
Vitor
