Mark Phippard wrote:
> I think it is more difficult than you make it out to be.
Granted, but just because it is difficult does not mean it cannot be
done, or that the logic couldn't be improved to improve performance.
> 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?
I was trying to come up with a plausible scenario based on my admittedly
ignorant and baseless understanding of how the Eclipse local history
might work. I have tried googling around to figure out if there are any
programmatic ways of interacting with Eclipse's local history but have
come up empty. From the sounds of it, the way Subclipse is currently
handling the preservation of local history is by somehow tricking
Eclipse. Is this workaround being used because of some shortcoming in
Eclipse or Subversion, or just because it was the easy way to do it?
The one thing I have read claims that Eclipse local history is stored in
the project metadata, hence I don't understand why reverting an
individual file would wipe the local history. Is this because Subclipse
is sending a delete event followed by a create/update event? Would there
be any way of just sending the update event?
>
>> 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.
Obviously there are plenty more cases than I enumerated. All I am
proposing is that Subclipse take advantage of the local status
information that it keeps available in memory/on the local disk to
optimize the revert commands given to the Subversion API. I think we can
definitely agree on the fact that there are plenty of cases where this
use case via Subclipse could be optimized. The fact (to the best of my
understanding) is that crawling local status information is relatively
inexpensive when compared to performing the actual revert command, so
using the former in order to minimize the latter would be a win.
>
> 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.
I think that would definitely be a good first step and provide something
that a contributor could build on. I would be happy to continue
brainstorming about the local history issue however I would need to be
pointed to a more comprehensive explanation of how local history in
eclipse is managed, if anyone has that resource available I would be
interested in learning more about it.
Cheers,
-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 21:23:28 2007