After a long absence, I was happy to see that someone had brought up this issue... then I checked the timestamp on the message, wasn't quite as happy. I think the wording used confuses the issue (on the first read/glance, it appeared to have been worded adequately).. So here is my re-interpretation of the poll & it's responses, since in the original message, both 1 & 2 seemed to indicate the same thing (see my option #2):::
QUESTION:
In the "Synchronize" view, what should happen in the commit dialog?
OPTIONS:
[1] The removed file should not be in the committed file list
[2] It should still appear in the list of committed files
MY VOTE, AND REASONING:::
I personally would vote for #1. When the user commits, the files listed would be generated just as it is now, with the exception that any files marked as "removed from view" would simply not be selected for commit.
NOTES:::
To get beyond the problem of files removed from the sync view being permanently invisible simply (using the term very loosely) re-generate the list whenever a refresh is performed--"refresh" referencing both manual & automatic ones. When the refresh happens, the list of files removed from the view should be discarded. I'm also assuming that automatic refreshes don't happen incredibly frequently.
Given the responses from Mark Phippard as of late, I would like to reinforce the idea that I am, in NO WAY expecting that he would be solely responsible for this code--if he's even involved at all. Figured I should make that quick addition to avoid any unneeded mental stress on him due to a misunderstanding. :)
(note to self: find a better teach-yourself-java book & learn it so you can start contributing to this project yourself)
On Wednesday 12 April 2006 12:45 pm, Daniel Serodio wrote:
> A month ago, there was a thread discussing "Remove from view problem"
> because:
>
> "... In the Synchronize view, if I choose a file and select "Remove from
> view", it still shows up in the commit dialog box." (Kevin Menard) [1]
>
> Mark's reply:
>
> "...If you select a folder and choose Commit, it just does the same
> stuff as if you had done it from the Team menu, meaning it figures out
> what to commit. You could not commit stuff for multiple projects in one
> atomic commit if we did not do it this way." [2]
>
> I really, really miss the ability to remove files (or directories) from
> view and not having them added to the commit. On the other hand, I've
> never "committed stuff for multiple projects in one atomic commit".
>
> So I thought about "running a poll" about which feature do users prefer:
> [1] or [2]? If most people prefer [1], we could rethink this
> implementation.
>
> Of course, I really appreciate Mark's efforts, and I have no intention
> to criticize his work or decisions, so I hope you see this as
> constructive criticism.
>
> Thanks,
> Daniel Serodio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
--
Best Regards,
Dan Falconer
"Head Geek",
AvSupport, Inc. (http://www.partslogistics.com)
Received on Wed Apr 26 18:43:05 2006