On Tue, Oct 30, 2012 at 01:57:09PM -0200, Vitor Barata wrote:
> A large part of the automatically-generated files contain source-code
> for language binding (Lua to C, Java to C and others). The system
> generates these files with .c/.cpp/.h extensions (so they can't be
> ignored based on the extension), but it does not enforce any
> convention on their names or on which directory they should go, this
> is freely configurable in custom project configuration files. This
> means that right now there is no global pattern that could be used in
> the global-ignores subversion setting.
We do exactly the same thing in Subversion itself, and we do have
ignore patterns like *.c and so on within the bindings source directories.
There doesn't seem to be any problem with this in our project.
This command lists the patterns we use:
svn propget -v -R svn:ignore https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings
I'm not quite sure if you really understand the impact of svn:ignore.
What behaviour are you expecting from the svn:ignore mechanism exactly,
and how would the expected behaviour impact your workflow?
Just to get a common misconception out of the way:
Note that you can add files that match an ignore pattern to version
control if you really want to. All ignore patterns do is suppress files
from appearing in the output of 'svn status'. And some IDEs use ignore
patterns to prevent some unversioned files from being suggested for commit
but they should still allow such files to be added to version control.
> > It seems your use case is rather exceptional. I've rarely seen the need
> > to ignore arbitrary files with names that aren't known in advance.
> > However, it's clear that the current ignore system isn't well suited
> > for this case, so maybe we should extend Subversion in some way to
> > account for this.
>
> The simplest and cleanest way I see to extend Subversion to account
> for this is to provide another special property, say svn:localignore,
> that would work exactly like svn:ignore, but that would be
> unversioned, so that it could be altered by automation systems like
> ours without making directories be marked as modified.
Based on past experience, I would guess that this is probably not as
simple as you imagine it to be, unfortunately. You are talking about
a major feature addition, not some small fix.
Subversion has no concept of an unversioned property yet.
Such a concept would need to be added first which would require some design
and implementation effort. A lot of work would need to be done to make sure
this new kind of property interacts well with all other features of the
system (status, diff, commit, update, ...). That means writing a lot
regression tests to start with.
This might turn out to be about as "simple" as the "file external" feature
turned out to be. A very simple idea on the surface but very hard to get
working correctly in all use cases, and we ended up frantically fixing a
lot of new bugs related to the feature over the course of several months.
Received on 2012-10-30 17:31:40 CET