Bugzilla – Full Text Bug Listing
| Summary: | No filters should be applied by default to a synchronized project | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | David Wootton <drwootton> |
| Component: | RDT.sync | Assignee: | John Eblen <jeblen> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | beth, g.watson, jeblen, roland |
| Version: | 5.0.4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Unix All | ||
| Whiteboard: | |||
|
Description
David Wootton
You can change the default for new projects in the workspace settings. Allowing the user to set this also in the wizard might be a good idea. Why would you want to include binaries by default? In general they won't execute on a different machine. And because of their size they add significantly to the transfer size (and thus time). Also, because the binaries will be different, they are causing merge conflicts, in case the user chooses to have the binaries in the same location on more than one machine. Our product requires the executable be synchronized to the local workspace so that it can be used to guide the tool interface. It is not necessary for the executable to be the same architecture in this case, as it is not executed. The existing behavior has been changed with the addition of the filters, so this needs to be reverted prior to 5.0.5. Thanks. I agree with Roland that, in general, the user would not want binaries to be sync'ed. Thus, I'm in favor of the current default. For special cases, like your product, the default can be changed on the "Synchronized Projects" preference page. I can revert it, though, if you still prefer. My reasons why I would like to keep the behavior as it is: A formal reason: The original behavior (both in 5.0 and in SR1) is that those files are not included. If we now change the behavior as you intend, we would change the behavior from SR1 to SR2. Also from the emails at the time when the behavior was originally changed, it was clear that this is intended to be a temporary workaround. For both reasons I think the argument, that changing the default behavior as you intend, constitutes a change in behavior (SR1->SR2), is at least as strong, as your argument, that John's patch is changing the behavior. A user expectation reason: As outline before, the behavior as in John's version is in our view the expected behavior for most users. Because the behavior can now be changed easily, there is no reason anymore to make default behavior depending on a requirement by a minority . As it should be possible for your product to change the default behavior outside of the regular version, I don't think this should should influence the behavior of the regular user. And because both significant performance and convenience ( merge conflicts) problems are caused by the other behavior, I think the choice of the best default behavior for the regular user is very important. There's two types of files we need access to for our product's Eclipse plugin to operate properly, where we expect the user to make the selection of the file from the project within the project explorer view. The first is the application executable where the user 'opens' the executable in order to populate some views that describe the structure of the executable and which are the first step in the tool workflow. If the executable is not visible in the project explorer view, the user has no way to select the executable. The other files we need to have access to are data files with a .viz extension which the user selects from the project explorer view to load into the tool. The user has the opportunity to automatically load these into the viewer immediately after a run, but has no way to open them in a subsequent Eclipse session if they don't appear in the project explorer view. Currently, if the user does not modify filter defaults, then these files don't appear. To be strictly correct, the change was made in 5.0.3 to sync any new files that are created on the remote system, not just executables. So either way (leaving as is, or changing) it will constitute a difference in behavior between PTP/Indigo versions. I disagree that the user would not want the executable synced. When I build the project, I want some indication that the build has been successful and that the binary is available to launch. Other than syncing the binary, there is no other mechanism to do this for sync projects. This is also the behavior for both local and remote projects, so it would be completely confusing to users if they see no change to their project after the build has been run. Similarly, if I run some tool that generates data, I want that to be automatically copied to the local system so that it can be visualized in the UI. It is not acceptable to us that the user would have to change the default setting manually. We are striving to improve usability by reducing the number of configuration actions the user has to make in order to use PTP. Adding yet another one configuration step is heading in the wrong direction. Our plugin will need to be able to set the default to disable your filters. However, I still think this should be the default setting, with an option on the new project wizard to add a filter if desired. (In reply to comment #6) > To be strictly correct, the change was made in 5.0.3 to sync any new files that > are created on the remote system, not just executables. So either way (leaving > as is, or changing) it will constitute a difference in behavior between > PTP/Indigo versions. Yes. I agree. > I disagree that the user would not want the executable synced. When I build the > project, I want some indication that the build has been successful and that the > binary is available to launch. Other than syncing the binary, there is no other > mechanism to do this for sync projects. The console and the status bar are two indicators that the build has been successful. Nonetheless I agree that it would be nice if the user would also see that the binary has been created. Ideally we would show all (or just the filtered) remote files in a virtual folder per remote host (similar to the "Includes" & "Binaries"). Obviously syncing the whole binary isn't an efficient way to show whether the binary is available. And it causes the problems which Makefile projects placing the binary in the same location. > This is also the behavior for both > local and remote projects, so it would be completely confusing to users if they > see no change to their project after the build has been run. It would be at least as confusing if the local binary is overwritten with a binary which can't execute locally. > Similarly, if I > run some tool that generates data, I want that to be automatically copied to > the local system so that it can be visualized in the UI. I agree. > It is not acceptable to us that the user would have to change the default > setting manually. We are striving to improve usability by reducing the number > of configuration actions the user has to make in order to use PTP. Adding yet > another one configuration step is heading in the wrong direction. I agree. But I would like the setting to not include executables for the same reason. > Our plugin will need to be able to set the default to disable your filters. > However, I still think this should be the default setting, To me the question comes down to which is more important to the average user: - They can see the remote binary has been created - Or, the sync is faster, they don't get merge conflicts, and their binaries aren't being overwritten with a binaries from a different (either other remote or local<->remote) system. You haven't addressed so far why you think that the advantages of John's setting are less important. > with an option on > the new project wizard to add a filter if desired. I agree that it would be nice to have this in the wizard. I have just committed a patch to ptp_5_0 that adds a button to the new sync project wizard for modifying file filtering. I haven't changed the default filtering yet, though. (In reply to comment #7)> > > I disagree that the user would not want the executable synced. When I build > the > > project, I want some indication that the build has been successful and that > the > > binary is available to launch. Other than syncing the binary, there is no > other > > mechanism to do this for sync projects. > The console and the status bar are two indicators that the build has been > successful. Nonetheless I agree that it would be nice if the user would also see > that the binary has been created. Ideally we would show all (or just the > filtered) remote files in a virtual folder per remote host (similar to the > "Includes" & "Binaries"). > Obviously syncing the whole binary isn't an efficient way to show whether the > binary is available. And it causes the problems which Makefile projects placing > the binary in the same location. Yes, that would be nice, but I suspect it won't be ready for 5.0.5. > > > This is also the behavior for both > > local and remote projects, so it would be completely confusing to users if > they > > see no change to their project after the build has been run. > It would be at least as confusing if the local binary is overwritten with a > binary which can't execute locally. I haven't heard of anyone who is building both locally and remotely, and would think that this scenario is probably an unusual one. It is much more likely that sync projects will be used as a replacement to overcome limitations of remote projects. I think also in such a situation the user would be well aware of what they are doing since they would have had to switch the active configuration. In any case, such a merge conflict could be easily resolved by simply allowing the user to choose either the local or remote version. > > > It is not acceptable to us that the user would have to change the default > > setting manually. We are striving to improve usability by reducing the number > > of configuration actions the user has to make in order to use PTP. Adding yet > > another one configuration step is heading in the wrong direction. > I agree. But I would like the setting to not include executables for the same > reason. I guess we disagree that the user would want to do this in most situations. > > > Our plugin will need to be able to set the default to disable your filters. > > However, I still think this should be the default setting, > To me the question comes down to which is more important to the average user: > - They can see the remote binary has been created > - Or, the sync is faster, they don't get merge conflicts, and their binaries > aren't being overwritten with a binaries from a different (either other remote > or local<->remote) system. > > You haven't addressed so far why you think that the advantages of John's setting > are less important. To summarize: 1. Users need feedback that their remote builds and/or other tools have actually done something. Until something else is implemented, the only way this can happen is by syncing the executable/data files. 2. A build that produced no change in the workspace would be different to all other project types, as well as a building a sync project locally. 3. Some tools require an executable or data file from the remote build/run to be available on the local machine to operate. 4. Building both locally and remotely is unlikely to be a common scenario. 5. A merge conflict could be easily resolved by allowing the user to choose one or other file. 6. A user may be aware that syncing a large executable is slow, so could cancel the sync and add a filter to prevent it happening. 7. A user is unlikely to be aware that there was a default filter that excluded the executable, and would be more likely to think that the build was not working properly. For the problems with including binaries see: - http://dev.eclipse.org/mhonarc/lists/ptp-user/msg01657.html - http://dev.eclipse.org/mhonarc/lists/ptp-user/msg01642.html While there are obviously pros and cons, I think the most compelling reason to sync binaries and everything else is:
>7. A user is unlikely to be aware that there was a default filter that excluded
>the executable, and would be more likely to think that the build was not
>working properly.
New users don't tend to look at the status area, and may not trust the console. Seeing the
executable built (and "seeing" means syncing in the simplest sense) is the best and most obvious
confirmation of the build.
And this is the same behavior as local projects. The more we can keep the same, the simpler for users, esp. new users. More experienced users will figure out the filters very quickly I believe, and set them to their liking.
Most of the new user troubles are related to missing something that the experienced user already "knows" and that is already documented. If more "just works" without tinkering (and they get visual confirmation that it worked) then they will continue on and tinker to get it more efficient. ("Hey! I don't need to sync the binaries now that I know it does build ok on the remote platform")
Roland and I discussed it and now agree that it makes sense to not filter binaries by default. The most important point, I think, is that it is more intuitive for new users while being easily changed by more advanced users. The default filter settings have been changed in master and ptp_5_0. Since the wizard also now contains a button to change the file filtering, I think all issues have been addressed, so I'll go ahead and close the bug. Feel free to reopen, of course, if something was overlooked. Thanks to all for a fruitful discussion. |