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.
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
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.
4.) Run "optimized" revert commands
5.) send "update" events again
In essence, a little work up front could result in fewer calls to the
Subclipse API by determining these "common" revert points. Granted my
example is convoluted/easy, however in my mind I don't think it would be
hard to devise a smart algorithm which is able to devise these common
"revert" points in an efficient manner.
Thoughts?
-Zach
---------------------------------------------------------------------
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:44:46 2007