On 9/18/07, Jay Levitt <lists-subclipse@shopwatch.org> wrote:
> On 9/18/2007 1:04 PM, Holger Hoffstaette wrote:
> > On Tue, 18 Sep 2007 10:23:48 -0400, Mark Phippard wrote:
> >
> >> On 9/18/07, Zach Bailey <zach.bailey@hannonhill.com> wrote:
> >>> Would it be possible to do a little work up front to determine if a
> >>> recursive revert were "safe" and automatically choose that option?
> >> Would it be possible? Of course. Would that make it safe? Not sure.
> >> It depends how smart we are. A related issue is that people wanted
> >> us to preserve local history when reverting. If we just switched this to
> >> a recursive revert we would lose that.
> >>
> >> You and I might think this is all fine, but someone down the road is bound
> >> to show up on the list angry because they lost work.
> >
> > What could be more clear in its intention than revert? When I select
> > revert on a file, I want that file reverted; when I select it on a
> > directory or the entire project, I want to blow it all away - otherwise I
> > wouldn't select revert but instead try to backtrack via the local history.
>
> I'm not sure that's what Mark meant. Mark, how does reverting via
> Subclipse differ (with respect to the local history) from reverting
> recursively at the command line?
Eclipse does not know about stuff that happens outside its API's. So
we have to essentially null out the file content using an Eclipse API
before calling revert so that Eclipse is triggered to take a current
snapshot of the file content.
The other issue is that our dialog allows you deselect items from the
revert. If we start using recursive reverts and we are not careful,
then stuff can be reverted that the user did not expect. Suppose you
want to do something like revert property changes to a folder, but not
a file change beneath that folder. That is an example where the
recursive option becomes dangerous.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Sep 18 20:08:50 2007