Would it be possible to do a little work up front to determine if a
recursive revert were "safe" and automatically choose that option?
Generally I get the impression that the time it would take to perform
this sort of calculation would pale in comparison to the time it takes
to revert even a couple of files due to the I/O involved.
Cheers,
-Zach
Mark Phippard wrote:
> On 9/18/07, Javier Kohen <jkohen@users.sourceforge.net> wrote:
>> I noticed that running Revert on a project's root takes too long. From
>> the console output it seems that Subclipse is invoking revert -N for
>> each file instead of doing it recursively in one go for the whole
>> project. Running revert for the whole tree from the command line on the
>> same project takes very little time.
>>
>> This project has over 6000 files, most of which are generated by Apach
>> Axis and cannot be split. In any way, since the command line handles it
>> speedily and that seems to be the point of reference, I think it's worth
>> considering the recursive revert option or something to that end.
>
> There is an open issue for this. I cannot think of a great solution.
> Doing a recursive revert from the existing option would be dangerous
> and easy to revert someone's changes that they did not want. The
> ideal would be to think of an appropriate way to add an explicit
> recursive revert option. Perhaps doing something in the "Replace
> with" menu where we could reasonably infer that the user intended to
> just do a recursive revert.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Sep 18 16:11:45 2007