Sorry if anyone receives this twice. There was a temporary glitch in my list membership so I'm reposting.
On Nov 19, 2009, at 12:00 PM, Quinn Taylor wrote: > Simply put, because Versions doesn't care whether or not a file is selected > if a parent directory is selected. Exactly. Actually I would say this is a bug. It feels to me like it violates the principle of least surprise, in that it's odd to deselect something and have the app behave as if I'd selected it. Consider the installer for OS X, which is another example of selecting from an expanded hierarchy. (Disclaimer: I'm describing this from memory.) You can click a checkbox to select or deselect an entire subhierarchy such as all the printer drivers. But you can also check or uncheck individual drivers in the list, and the checkbox for that subhierarchy changes to a minus sign. I'm not saying Versions should use checkboxes in the main file list (IMO that would be a terrible idea). I'm just pointing out a precedent for a UI that supports the concept of a hierarchy with only some items selected. > Because it's often a lot more work than removing a single resource, and as > I've stated, with hierarchical selection, it can be non-trivial to select > "everything but". No offense to anyone, but the replies to this thread are > starting to sound increasingly dogmatic. I'm not sure if it's dogmatism, more likely people are missing your point above or don't have project hierarchies or workflows where they run into this issue. I'm with you -- I would like checkboxes in the commit dialog -- but I also came to Versions after using Subclipse, so it's possible I could seem dogmatic on the other side. :) As a slight variation of the "exclude one file" workflow, there are times when I do want to commit all changed files, but I find the changes I've made can naturally group into smaller subsets. For example, in the course of fixing bug XYZ, I may have added some generically useful accessor methods in some data classes, and in one other file I may have changed some business logic that is specific to the bug. Rather than do a total commit with a comment that explains all the above, I would do two smaller commits, each making sense in its own right, with a comment specific to that commit. Fewer files per commit makes it easier later on to understand the purpose of a given commit. If the purpose of the overall change was to fix bug XYZ, it's easier to see what specifically fixed that bug if there's a smaller number of files to look at. If you think a change you committed may have introduced a new bug, it's easier to track it down by rolling back a series of small commits than one "big bang" commit. And as a side benefit, you can give the impression that you methodically made a sequence of incremental changes when really you were changing things willy-nilly in the course of chasing down the bug. :) --Andy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~----------~----~----~----~------~----~------~--~---
