On 29.03.2017 11:55, Richard Haselgrove wrote: > I was thinking of things like > > <!-- SVN VERSIONS --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id$ --> > <!-- $Id: pm.inc 14019 2007-11-01 23:04:39Z davea $ --> > <!-- $Id$ --> > > (from https://setiathome.berkeley.edu/forum_index.php) > > We used to be able to see exactly which SVN patches had been applied by any > given project, and advise accordingly.
That was the poor man's version of a proper server version management. It stopped working with the svn to git migration. I agree it is a nice way to see what version projects have running. But it also opens a can of worms with regards to security. There might be projects that don't want to expose this kind of information because then it would be easier to spot vulnerable pieces of code. A proper server versioning as well as release management could bring this feature back. > Would there be a way to keep the auto-generation of the date and author > fields, even though the Git SHA isn't helpful in this situation? The SHA1 would still be the best way to show the version but is not useful because of the way git works. Every project obviously has a clone of the main BOINC repository but they won't just checkout this and use it on their production webserver. They probably have a separate branch in this repository where they track project specific files and changes to BOINC files. This way it is easy to see differences between BOINC and the project and also inspect changes done to BOINC. New changes coming in from BOINC can then be merged into a testing branch and after testing into the production branch with a simple "git merge master". This way a project can always fall back to the last known good configuration if something goes bad. In this scheme the SHA1s are useless because they are specific for this non-public repository and won't help any external troubleshooter. Even if some information is added the only thing an external troubleshooter can do is tell the project to update this file because it might contain a fix. The better way would be to point the project to a specific commit that fixes the problem and they can check if they have this commit in their fork of BOINC that they use. If they don't have it they can investigate if they can cherry-pick that or merge all commits until this one into their branch and deploy on their server. > Projects also used to show a single SVN number on their server status pages, > which gave a glimpse of the state of their operational server code. The same security concerns as above apply here too. With proper versioning you would have a number or something here but It could only reflect the version of the main BOINC repository that was used to create the project specific fork. You still don't know what versions the daemons are built from and how heavily modified they are. Our daemons actually display (using --version) two SHA1; one of the repository where we keep BOINC and one of the repository where we keep our project specific daemon code. This way we exactly know what code changes are in the daemons and which are not. If a project does not have the resources to troubleshoot server related things on their own and need the help of volunteers this might be a legitimate reason to display such version information but if a project does not want to publish that they should be able to disable this completely. Regards Christian _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
