Mark Phippard wrote:
>>> I agree completely. I just came to the conclusion that it is a
>>> different issue than this one and can be dealt with
>>> differently. For example, there could be a property like
>>> subclipse:branches added that has information about branches
>>> and this could be used to better drive a Compare with Branch
>>> option.
>> There is some overlap between this possible "branches" property and
>>property with tags you have suggested before. Besides, for "compare
>>with..." action it doesn't really matter if it is a branch or the tag.
>>So, why not avoid duplication and use the same property in both cases?
>
> We have gone over this. The difference is that when we are making the tag
> assumption we can use the existing Compare, which just contains two
> revisions of the SAME url. By adding the tag information to the view, it
> allows you to better leverage this existing feature. The Compare with ...
> action would also need to exist and that is where we could make some
> enhancements to support comparing DIFFERENT url's, whether tags or
> branches.
All I am saying it that path value won't hurt.
By the way, you can also mark branches specially, so it will be
possible to differentiate branches from tags from the history view and
later implement various comparison options or even show tag/branch
graph, which would need to know these path's, so please consider to
put them in.
>>> I just decided to leave that out for now. The file wouldn't be
>>> in your workspace and I wasn't sure what API Eclipse offered
>>> for opening files in editors that are not in your workspace.
>>> If you want to look into this and send a patch, that would be
>>> great. Otherwise, I will come back to it later.
>> It would be nicer not to have file outside of workspace or even
>>have no file at all and use in-memory buffer or temporary file as a
>>last resort. Does it has to be a file?
>> In any case it should be possible to implement a custom EditorInput
>>to show this file in editor or even in a standard comparison editor.
>
> Like I said, I agree completely. I just wanted the basic feature
> implemented since it was completely missing. This will make it easier to
> motivate someone to make it work better. If someone could take the output
> of that diff (which is just a stream) and could use it to drive the
> Eclipse compare that would be awesome and could bring a huge leap in
> usability. I think it is kind of a tough problem though.
I think it should already exist in CVS plugin. I would imagine that
they also receive stream with an unified diff from the server and then
show comparison editor from it. I can take a look or ask Team/CVS guys...
regards,
Eugene
Received on Tue Dec 6 08:26:27 2005