> Anyway, when I disable valid_product_name, I would expect no matching
> problems. However, it seems that matching the regular expression is
Disabling valid_product_name disables verification of the product name.
It does not disable autodetection of the product name. Perhaps this is
the problem here.
In order to detect labeling operations, a product name MUST be
available. Either manually defined, or automatically detected. We need
to separate between valid_product_name validation, and
product_name_detection.
On Wed, 2007-04-25 at 11:30 +0200, Hofman, Peter wrote:
> When valid_product_name with regular expression '([^/]+/[^/]+?)/' is
> disabled, it works.
Do you mean that you relaxed the 'value' restriction ? Or do you mean
that you have switched to a manual type, e.g. you have set:
valid_product_name => {
enabled => 1,
type => 'manual',
value => 'CustomerA/ProjectY'
},
This 'workaround' of using a manual mode would work, yes.
> But then some other interesting stuff showed up in the bug:
OK, the following is totally unrelated to product name detection.
> Branch: Cannot_be_determined
> Affected files:
> ---------------
> NONE --> 294 CustomerA/ProjectY:CustomerA/ProjectY/
> NONE --> 294 CustomerA/ProjectY:CustomerA/ProjectY/branches/
> NONE --> 294 CustomerA/ProjectY:CustomerA/ProjectY/tags/
> NONE --> 294 CustomerA/ProjectY:CustomerA/ProjectY/trunk/
>
> E.g. where did the source revision go? I did not expect NONE, but at
> least the revision of the root of the repo.
When a file/directory is added, it's history is looked up.
CustomerA/ProjectY is a new directory -- it has no history. Hence, NONE
is displayed to represent that fact. You should see this model of "NONE
--> <some_number>" for all new file/directory additions. This is
intentional. It is also easy to determine that the previous version of
the roop of the repository was 294 - 1 = 293.
The reasoning behind this model is that the two version numbers will be
also used for autolinkification, and NONE would indicate that there's no
such prior version for this directory. The source revision makes more
sense when a file is modified: it is then desired to show the previous
revision at which a file was last modified, not the previous revision of
the entire repository (which will always be one less than the new
revision).
> Why is a product name mentioned? It was supposed to disabled.....
valid_product_name verification is disabled. But the product name is
always supplied during an integration request and reported in the logs.
It is always supplied, but simply not verified if valid_product_name is
disabled. Again, this product name will be used for autolinkification.
> Besides the problem described above (which has a workaround) we have not
> had any issues with scmbug yet. In fact we are very pleased with ScmBug.
>
> Keep up the good work!!!
Thanks for the kind words.
I still haven't looked into why the error occurs. I'm trying to
reproduce it in a test case before I can attempt debugging.
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
