Mark Phippard wrote:
>> Mark, for CVS integration this functionality is actually provided by
>>special "date tags" and Synchronize view. You can create date tag in CVS
>
>>repository view and then compare it with another date tag. Comparison
>>results are shown in synchronize view. There is an overlap in
>>functionality that is already provided by svn history view and what cvs
>>sync view provide in "Commit Sets" mode.
>>
>> To maintain user experience it make sense to do it the same way for
>>svn. That, however, will require to support "commit sets" feature for
>>SVN syncronize view.
>
> I don't agree. I think it makes sense to do it the way that is supported
> by Subversion, and that is to provide dates as inputs to the revision
> parms on the svn log command. The existing client adapter API should
> already support this. This is something we could implement in our
> existing view and would be the expected Subversion behavior.
Well, Subclipse could provide both options - from history and from
synchronize view. I'm sure that long-time CVS users will appreciate that.
Note that sync view is more persistent then history and already
provide more then one panel. History view can be also linked with the
editor (well, may it is just me again) and when user switch to other
editor its content will be refreshed. This aren't going to happend with
sync view.
I have itch to get an update action from history view, but it would
be really better to implement sync view features like commit sets.
Currently I feel blind looking at svn sync view in incoming changes
mode, so I have to run svn history for the whole project in order to see
what was going on with the project, but it is not quite the same,
because I can't run update from history view and it is also show too
many changes (sync view in cvs show changes from the head up to local
revision).
>>>a) make compare enabled in more circumnstances. Currently, you can
> only
>>>do compare if you are showing the revisions for a specific file.
>> So, if history view shows folder it should bring up folder comparison
>>then?
>
> I was more thinking just that the compare options should be enabled.
> Ideally you could select a file from the affected paths list and compare
> it with the working copy.
Right
>>>b) perhaps provide a few compare options. Such as showing the
> specific
>>>change for that revision (probably in diff format). Comparing against the
>>>local pristine copy vs. the local edited copy. Perhaps options to
> show
>>>unified diff of the entire revision? Like a patch option?
>>
>> I presume that I can look at quick diff implementation to see what
>>API to use for diff with pristine copy?
>
> I am not really sure. Presumable the Compare with -> Base revision does
> this too?
Does "compare with base revision" actually comares with pristine copy?
regards,
Eugene
Received on Tue Jun 21 03:25:31 2005