Mark Phippard wrote:
>>> I do not underestimate that at all. That is really a different
>>> problem in my opinion. When looking at the history of a file on
>>> trunk for example, I do not see any direct relationship between
>>> that history and a branch, which would have its own history and
>>> for which trunk may have been merged to that branch. You are
>>> expecting way too much here if you think this can be addressed.
>> It would be really handy to be able to compare revision from
>>history with branch using either starting revision or latest revision
>>in this branch.
>
> 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?
>> You can also show unified diff in a plain text text editor (maybe
>>with some basic outline), so user won't have to choose where to save
>>file and then look where it was saved and open with some external
>>editor (very annoying to me).
>
> 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.
>> Right. I just suggesting to slightly change priorities. One still
>>could use standard svn property editor to update this information. So,
>>I think it is more important to handle properties on copy/tag/branch
>>from the beginning.
>
> I envisioned completing all 3 milestones before doing a release. I was
> just logically separating what I thought the issues were. I think being
> able to manually edit the properties is more important first.
That could fit nicely as a custom editor in a Properties view...
>> How about add relative url (actually path from the repository root)
>> to the properties for now? So, later we could pickup this
>>information. It is better to have it here at least as a hint.
>
> All I can say is maybe. I think it potentially adds a lot of complication
> to the design. I want to be sure it is worth it.
It won't hurt to have it as a kind of "comment" that will be
ingnored for now.
regards,
Eugene
Received on Tue Dec 6 06:20:08 2005