Re: [boinc_dev] BOINC-v2 Git Repo Updated
On 3/1/13 18:00 , Rom Walton wrote: While doing further consistency checks I found the following v2 commit: http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=723c1f5667 2c6853e203578693254653f0680e04 Where does it come from? I can't find it at all in v1: http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=history;f=lib/network. cpp SHA1: 131f868eee1f472fb5900959c995bcdcb3f126cc Now that's indeed an interesting one: it's supposedly just a merge of v1's 1f099ac but at the same time it contains a seemingly unrelated change to lib/network.cpp that's not even documented (e.g. in checkin_notes)... I've cloned your repo and am taking a look. It might be better to just add my repo as another remote instead of cloning it as a separate repo as it facilitates diff'ing. Beware: there might be forced updates (changing SHA1s) in future pushes since this is all work in progress... Cheers, Oliver ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
Hi Rom, On 2/25/13 18:14 , Rom Walton wrote: Now we come to the extraction of patch sets from v1, the patches reference SHA-1 values that exist in the botched SVN migration. So git-am would complain about missing SHA-1 values and abort. In order to fix that situation I created a new branch, manually applied the patch, extracted the patch, copy the patch header from the old patch file to the new patch file, rename new patch file to the old patch file, checkout master and apply modified patch. On 3/1/13 17:20 , Oliver Bock wrote: Also, the way you generated the patches (straight git format-patch) linearized the history and changed the order of several commits (a known effect). In contrast, I replayed the original history as close as possible which makes it easier to do v1/v2 cross-checks Comparing your v2 with my v2 I also found a number of white-space changes, presumably introduced while you edited/recreated the patches manually, something I usually didn't have to do. I only used combinations of format-patch/am and cherry-pick with v1 SHA1s, no need to construct new patches. At some point (rather sooner than later) we should decide how we're going to continue in order to avoid doubling the effort. In my migration attempt so far I didn't have to manually edit any patches for the reasons you described, naturally avoiding any accidental changes of content (incl. whitespaces). My approach also doesn't linearize/flatten history or change the order of things. Since we, E@H, really do care about BOINC's code base and history I could offer to continue my effort until our repo is in sync with upstream. Thoughts? Best, Oliver ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
Hi Rom! Oliver Bock wrote, On 04.03.13 14:40: At some point (rather sooner than later) we should decide how we're going to continue in order to avoid doubling the effort. In my migration attempt so far I didn't have to manually edit any patches for the reasons you described, naturally avoiding any accidental changes of content (incl. whitespaces). My approach also doesn't linearize/flatten history or change the order of things. I prefer Olivers approach of changing the current history as little as possible. The main reason is that there might work already been done based on the current history, e.g. branches. The more changes you make to the old history, the less likely it is that in the new history you will find a point (i.e. commit) that corresponds to the state of the whole tree that your previous work refers to, e.g. the commit where your branch forks off, and which you could use to re-implant your branches to. Since we, E@H, really do care about BOINC's code base and history I could offer to continue my effort until our repo is in sync with upstream. I would vote for accepting the offer and let Oliver finish the migration. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
On 3/4/13 11:58 , Oliver Bock wrote: On 3/1/13 18:00 , Rom Walton wrote: While doing further consistency checks I found the following v2 commit: http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=723c1f5667 2c6853e203578693254653f0680e04 Where does it come from? I can't find it at all in v1: http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=history;f=lib/network. cpp SHA1: 131f868eee1f472fb5900959c995bcdcb3f126cc Now that's indeed an interesting one: it's supposedly just a merge of v1's 1f099ac but at the same time it contains a seemingly unrelated change to lib/network.cpp that's not even documented (e.g. in checkin_notes)... There's another one of this kind: http://boinc.berkeley.edu/gitweb/?p=boinc.git;a=commit;h=efcb81f86d602b3042d04d14ac32e78c3b250e94 Please note that the gitweb content display of this commit is incomplete since overall 22 files got changed. The problem is that this merge added a change to client/Makefile.am, without a parent commit containing it that is. Furthermore the merge dropped two changes without a conflict being present: - sched/sched_send.cpp in f51b328 - client/cs_scheduler.cpp in 1a76e1a I'm not sure these additional changes should have been part of the merge since I can't find any reasoning or justification for them. I suggest you, Rom and David, revisit that commit and make sure all changes are indeed intentional. For the future I recommend to change things during a merge only to solve conflicts, don't add/remove/change anything apart from that if possible - at least not without further documentation. Cheers, Oliver ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
On 3/4/13 16:23 , Oliver Bock wrote: The problem is that this merge added a change to client/Makefile.am, without a parent commit containing it that is. Furthermore the merge dropped two changes without a conflict being present: - sched/sched_send.cpp in f51b328 - client/cs_scheduler.cpp in 1a76e1a FYI, the checkin_notes version of that commit also doesn't reflect the three extra changes which indicates that those changes might have been introduced unintentionally... Oliver ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
On 3/1/13 17:20 , Oliver Bock wrote: I'll continue my migration this way... Update: reached January 2013... Oliver ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] WUs with abnormally high deadlines
Hi all, I am having an odd problem with the boinc server. There are a handful of WUs that have an extremely long deadline (~May 7th) even though the deadline is set to 7 days by the project. It's only happening with 1 user and this user claims to have detached from the project. Is there an easy way for me to free up these WUs so that they can be reissued to another user? I know I can cancel the WUs from the main admin page and then re-create them, but I thought there might be an easier way. Also, does anyone know what could cause this behavior? Thanks! Eric Driver NumberFields@home ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
