On 9/18/07, Zach Bailey <zach.bailey@hannonhill.com> wrote:
> All,
>
> Mark Phippard wrote:
> > 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.
>
> I don't think this really precludes the option of doing a recursive
> revert subversion call. This part should always be done before the
> actual subversion API calls are made to revert the artifact, regardless
> of the subversion calls made.
I think it is more difficult than you make it out to be.
> In my mind it would go something like this:
>
> 1.) User selects to revert and is prompted with "select files" screen
> 2.) Each of the selected files are "prepped" such that local history is
> not lost, as you say the contents are nulled (and then an "update" event
> is triggered to eclipse?) or whatnot
OK, currently it is done as part of the revert. We can do this ... it
would probably be OK ... but it is also introducing a time-gap window
where a lot can go wrong. What if an error occurs between this step
and the revert? What if the user cancels?
> 3.) Determine common recursive revert points. For example if I have two
> files I choose to revert, src/java/com/Foo.java and
> src/java/com/Bar.java my "common" revert point would be src/java/com as
> long as src/java/com is not modified or if it was ALSO selected as an
> asset to revert.
Harder than it sounds. What if src/java/com/FooBar.java is also
modified but not selected? A recursive revert is going to lose its
changes.
The best algorithm would be one where we did the recursive revert
based on the item you selected (such as the Project) but with some
kind of best effort check that all modified items are selected in the
dialog. If this is not true, then fall back to current non-recursive
revert. That said, I still think the Eclipse local history issue does
not have a good answer yet.
--
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:57:33 2007