Community
Participate
Working Groups
When synchronizing project that have number of local changes, status of the sync job is not very informative, because it show only total number of changes. It will be very helpful to have separate numbers for incoming and outgoing changes.
Created attachment 39260 [details] suggested implementation I wonder if this can make into 3.2. Thanks in advance.
Thanks for the patch. Unfortunately, it is not possible to include it in 3.2. Here'a a list of reason to justify this decision: 1) We have been asked to minimize string changes to those that are essential as the translators are already working on translations. 2) The separator used (";") would need to be translatable but is not. 3) Conflicting changes are not considered (i.e. the API you used for the model sync case would miss conflicting changes). 4) I didn't test it but I noticed that, for the old sync case, you performed an OR comparison where I think you should have done and AND. 5) we have two days to get code changes into 3.2 RC2 and after that the rules for getting changes in become more strict. Unfortunately, we have a full plate of things to do during that time.
(In reply to comment #2) > Thanks for the patch. Unfortunately, it is not possible to include it in 3.2. > Here'a a list of reason to justify this decision: > > 1) We have been asked to minimize string changes to those that are essential as > the translators are already working on translations. > 2) The separator used (";") would need to be translatable but is not. Hmm. I wonder what it could be translated to? > 3) Conflicting changes are not considered (i.e. the API you used for the model > sync case would miss conflicting changes). I thought that conflicting is just a mask aggregating both incoming and outgoing. Besides, there is still total number. So, you can get rough idea what part of that total is incoming and what is outgoing. > 4) I didn't test it but I noticed that, for the old sync case, you performed an > OR comparison where I think you should have done and AND. You are right, it should be bitwise AND. However I wasn't able to see when RefreshSubscriberParticipantJob is called, so I implemented it just in case. Actual sync job is calling RefreshModelParticipantJob implementation. > 5) we have two days to get code changes into 3.2 RC2 and after that the rules > for getting changes in become more strict. Unfortunately, we have a full plate > of things to do during that time. This is just a cosmetic but very useful change. Also, no API changes.
If it wasn't for point 1 I would consider sunmitting it but I have double checked with the PMC and we are not supposed to make string changes unless we absolutely must.
Patch released to HEAD. Thanks again.
By the way, Michael, do you think it would be useful to add incoming/outgoing changes decorator to the icons on Synchronize view synchronizations dropdown?
I tend to work with a single pinned Workspace synchronization so I personnaly wouldn't find it helpful. However, I can see that if you used multiple pinned synchronizations, you would want a way to easily find those that have changes. You may want to look at bug 146075 as it is somewhat related (i.e. the view title could be made bold when new changes appear in the view). We've had some discussion as to whether the sync view drop down is the right way to go or if it would be better to split each synchronization into a separate view instance. If that were done and bug 146075 were fixed as well, you would be able to see which Synchronizations had new changes in the view tabs.
(In reply to comment #7) > I tend to work with a single pinned Workspace synchronization so I personnaly > wouldn't find it helpful. However, I can see that if you used multiple pinned > synchronizations, you would want a way to easily find those that have changes. Right. I have 6 pinned and having real trouble to see which ones has changes. BTW, this patch probably does not cover job title, and all finished synchronization jobs look alike - "Sheduled Synchronize (Finished)" even so they do show working set name while job is running. Can you please address it? > You may want to look at bug 146075 as it is somewhat related (i.e. the view > title could be made bold when new changes appear in the view). We've had some > discussion as to whether the sync view drop down is the right way to go or if > it would be better to split each synchronization into a separate view instance. > If that were done and bug 146075 were fixed as well, you would be able to see > which Synchronizations had new changes in the view tabs. Hmm. I don't think it will help me because most of my synchronizations always have outgoing changes. I also don't think it would be a good idea to force each synchronization into separate view. I simply don't have space on the screen where I can stick those views. It would be more convenient to be able to mix synchronizations from separate providers within single synchronization.
If there are issues you feel that need to be addressed, pleasse open bug reports for them.
I've added the following copyright to the files of this patch: Eugene Kuleshov (eu@md.pp.ru) - Bug 138152 Improve sync job status reporting Let me know if it should be something else.
