svndigest property to override file extension setting parsing properties is needed

[Jari Häkkinen]

Files like source:trunk/test/test_repo.sh.in should be treated as a bash script but since the file ends with .in it cannot be assigned to bash parsing. We should add something like svndigest:parsingmode that could override default parsing mode.

[Peter Johansson]

Well, from my horizon, it ends with .sh.in so we could add a rule: *.sh.in files should be interpreted as bash script.

also see #122

[Jari Häkkinen]

In principle yes ... but should have a similar rule for all possible ...in files? Does ticket:122 rule out this ticket? I think this ticket is valid even if we add sh.in as a rule or have configurable associations.

[Peter Johansson]

No, ticket:122 does not rule out this issue, but we should have ticket:122 in mind; and I suppose it is clever to wait with this issue until ticket:122 is implemented.

Still, I don't like the idea. Your solution would be great if the problem were problems with exceptions to the file name rules. It could, e.g., be that you had a file named file.h containing perl code. Then it would make sense to mark the file as an exception to not follow regular name conventions.

You are reporting a different problem. The suffix .in is used quite often and for many types of files. It would be stupid to add a rule for every file extension X to also work for X.in. Instead one could perhaps make svndigest a bit smarter, by adding the feature to ignore some parts of the name. In this case we want .in to be ignored so when the Parser gets a file named test_repo.sh.in, the Parser ignores the trailing .in and only sees test_repo.sh.

[Jari Häkkinen]

Ok, lets make svndigest to parse files according to rules according to filetypes when the trailing .in is removed. If we need my suggestion we can add it sometime later. Is this easy to add, i.e., should we have in miletone:0.6?

[Peter Johansson]

fixed in [339]