Opened 12 years ago

Closed 9 years ago

#326 closed task (fixed)

setting ignore-patterns in config file

Reported by: Peter Johansson Owned by: Peter Johansson
Priority: major Milestone: svndigest 0.9
Component: configuration Version: trunk
Keywords: Cc:

Description (last modified by Jari Häkkinen)

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.

Change History (10)

comment:1 Changed 11 years ago by 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.

comment:2 Changed 10 years ago by Peter Johansson

Milestone: svndigest 0.8svndigest 0.9

comment:3 Changed 9 years ago by Peter Johansson

Status: newassigned

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"

comment:4 in reply to:  3 ; Changed 9 years ago by Jari Häkkinen

Description: modified (diff)

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?

comment:5 in reply to:  4 ; Changed 9 years ago by 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

comment:6 Changed 9 years ago by 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.

comment:7 in reply to:  5 ; Changed 9 years ago by 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

comment:8 in reply to:  7 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by Peter Johansson

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

comment:10 Changed 9 years ago by Peter Johansson

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.