setting ignore-patterns in config file

[Peter Johansson]

This should behave just like property svndigest:ignore does today.

Motivation for this feature:

• It is more convenient to set a pattern e.g. *.java than setting the property on each of these files. In principle one could use subversion's autoprops for this, but allowing this in svndigest also allow the user to set this afterwards. In ​baseplugins for example they use a non-standard tree structure with tags and branches far out in the tree. This feature would allow a user to ignore all tags for example.
• It allows a user to set ignore also when running on repository he does not have write permission on.

The feature is simply a list of file-patterns that should be ignored. These are set in config. Then we could have function in Configuration class

bool ignore(const string& filename) const;

that should be used in Node::ignore.

[Peter Johansson]

This should not be limited to svndigest:ignore, but should include all supported svn props. Currently this is only svndigest:ignore but there are plans for example for ignore_copyright property. It should be possible to set these in the config file as well. Perhaps this is redundant to support both svn props and config file, but if we should drop anything we should drop the svn props support because setting it in config file is more flexible. In other words, we should have a section svn-props section in the config file.

[Peter Johansson]

A question here: when we do the matching should it be based on the file name or on the path?

For the codons we work on the file name, but I suppose it is more flexible to match on the whole path as it allows pattern such as "*/test/README"

[Jari Häkkinen]

Replying to peter:

For the codons we work on the file name, but I suppose it is more flexible to match on the whole path as it allows pattern such as "*/test/README"

This would of course match all README files in a directory test. If you decide to set a pattern README I suppose it should match all files name README but in my view this is not obvious. Following your example the pattern should be */README but I am not sure that is wanted. One way to avoid it is to use test/README or ./test/README. I realize while writing this that we need to define from where the pattern matching starts. And it should be from the current directory, and then your example makes sense to me. We would have

`cwd`/*/test/README
`cwd`/README
`cwd`/*/README
`cwd`/test/README
`cwd`/./test/README

for the five examples discussed sofar. The current working directory of course changes as the directory tree is traversed. This means that the third example would not match a REAMDE in the search root directory (compare matching using ls). This leads to another thought, since ls does some nice pattern matching the functionality surely exists in a lib somewhere, maybe we can use it?

[Peter Johansson]

Replying to jari:

for the five examples discussed sofar. The current working directory of course changes as the directory tree is traversed.

Wouldn't that be confusing for the user? It implies I need to understand how the tree is traversed when I'm writing the config file. I thought the obvious choice to make paths relative to rootdir.

This means that the third example would not match a REAMDE in the search root directory (compare matching using ls). This leads to another thought, since ls does some nice pattern matching the functionality surely exists in a lib somewhere, maybe we can use it?

ls does not handle the wildcard in any way but it is expanded by the shell (try ls "Makefile.am" and ls "Makefile*"). Anyway, there is a function fnmatch in C api that we already use in svndigest (see lib/utility.h)

Sorry, my question was not clear. What I mean is whether we should do the pattern matching a la ls or a la find.

If we, for example, in svndigest topdir run

ls Makefile*
ls */Makefile*

The first will match Makefile, Makefile.am and Makefile.in and the second will match the corresponding files in sub-directories bin, lib, man, test, yat.

If we on the other side run

find . -name "Makefile*"

will match all Makefile, Makefile.in and Makefile.am in all sub-directories (as well as sub-subdir.. etc).

So the question is, when we write

svndigest:ignore = Makefile*

should we ignore only files in topdir (as ls only displays files in topdir) or should we ignore Makefile, Makefile.in and Makefile.am in all subdirs (as find matches all these files).

I think I'm starting to prefer matching on filename (as find) because 1) that is how we do for codons, and 2) it implies we can ignore tags and branches simply by

svndigest:ignore = tags branches

[Jari Häkkinen]

I prefer the find way to do it. I just didn't connect you example to it and rather got into the shell expansion route ... skipping a long tedious discussion ... go for the find way.

[Peter Johansson]

Replying to peter:

I think I'm starting to prefer matching on filename (as find) because 1) that is how we do for codons, and 2) it implies we can ignore tags and branches simply by

svndigest:ignore = tags branches

In order to allow for future usage of the value (#387), we should go for format

file-pattern property value

[Peter Johansson]

Replying to peter:

In order to allow for future usage of the value (#387), we should go for format

Forget that. We should, of course, use same format as subversion.

[Peter Johansson]

(In [1144]) refs #326. Let SVNproperty retrieve info from config file

[Peter Johansson]

(In [1152]) allow config file to override svn property (fixes #326). Adding two new files (split.h and split.cc) from yat.