Hello,
I have a comment/request on this error message from GetComponents:
./bin/GetComponents --update --verbose
[...] Error: The URL for KrancNumericalTools/GenericFD has changed, please perform a clean checkout.
After showing the below error message, GetComponents stopped. But maybe a user doesn't want to perform a clean checkout every time such a mismatch occurs. I suggest to change the error message so that it instructs the users to solve the problem (by manually checking out the new repository) and then rerun GetComponents. Even better, GetComponents could do something like renaming the old checkout "thorn" to "thorn.old" and checking out the new repository.
In any case, it would be useful if this error could be made non-fatal, namely if one could continue to update of the other thorns even without the failed thorn.
What do you think?
Cheers, Luca
Hi Folks,
I would like agree to Luca in that sense that such an error should not be a fatal one. However, a user must be informed that a checkout of a repository has failed. This mus be ensured. I am not that expert in GetComponents to know whether simfactory creates always log file. As far as I know it only writes message to the console, and if the buffer of te console is to small, a user might get lost of the message text.
Best wishes
Alexander
Hello,
I have a comment/request on this error message from GetComponents:
./bin/GetComponents --update --verbose
[...] Error: The URL for KrancNumericalTools/GenericFD has changed, please perform a clean checkout.
After showing the below error message, GetComponents stopped. But maybe a user doesn't want to perform a clean checkout every time such a mismatch occurs. I suggest to change the error message so that it instructs the users to solve the problem (by manually checking out the new repository) and then rerun GetComponents. Even better, GetComponents could do something like renaming the old checkout "thorn" to "thorn.old" and checking out the new repository.
In any case, it would be useful if this error could be made non-fatal, namely if one could continue to update of the other thorns even without the failed thorn.
What do you think?
Cheers, Luca _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org