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
-~----------~----~----~----~------~----~------~--~---

Reply via email to