Mark Phippard wrote:
>>-- First of all I think you are underestimate importance of comparison
>>between branches. I do believe that comparison with static tags is too
>>restrictive.
>
> 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.
> The current release has the ability to do an ad-hoc compare
> with a branch and we will hopefully improve that over time as we better
> integrate it with the Eclipse GUI features.
Right. Common comparison editor would be nice.
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).
>>-- Proposal is heavily based on artificial tags and suggesting special
>>editor UI for managing these tags. This not only increases development
>>effort but also makes user experience more complicated and less obvious.
>
> Exactly, the entire thing is artificial and will be since Subversion does
> not support this.
>
>> It seems that the cause of this issue is that SVN does provide
>>information on where particular issues were copied from, but not the
>>opposite. So, it is difficult to tell what tags/branches had been
>>derived from given stream. I think it is a good idea introduce svn
>>property at the folder used as a starting point for copy operation and
>>store information about the targets up there. I just suggest to actually
>>save target url (and NOT target revision as you suggested), along with
>>label/tag, which by default will be the same as the name of target
>>folder (so, copy/branch/tag action would have to request this from the
>>user).
>> We may still have editor for these tags, but in most of the cases I
>>think it should be transparent to the user and provide more flexibility
>>for linking/comparing tags/branches.
>
> The main point of the editor is to let people "initialize" the property in
> existing repositories with all of this information. My proposal already
> included the idea of keeping the property up to date when the copies are
> made (assuming they are done in Subclipse).
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.
> The revision is absolutely essential. If you do not have the revision
> number then there is no feature. How does the history view show the tags
> associated with a revision without this information?
Good point. Then revision, tag and url. :-)
> I do not want to store URL's for a number of reasons.
>
> 1) A full URL encodes the repository access method into the feature. It
> also creates problems if the repository is moved/renamed or restructured.
>
> 2) A relative URL solves the access problem. I do not know how easy or
> difficult that feature would be to implement but it seems like it is still
> potentially fragile if the repository is restructured.
I think relative url (path from the root) would be a good idea
because similar path already used for "copy from".
I wonder if repository restructuring would handle revisions and
"copy from" information?
> Finally, I am not sure what I would do the URL if I had it. Or what
> features it would allow us to provide that we do not already. For
> example, one of the nice features of this proposal is that it allows us to
> leverage our already existing graphical compare when looking at the
> revisions of a file. It just enhances the feature by providing more
> information in the history to allow you to more quickly decided which
> revisions to compare. As I understand it, that is the primary goal behind
> this entire request.
In my view it would allow to compare with current branch revision,
which is more important then comparing with initial branch revision as
you suggested.
Also, given not strict SVN repository structure url would give a
good hint to the user, where to look for branches and should also
allow to simplify "Replace with tag/branch..." action.
> I think this is key. For me, it was the realization of these facts, and
> that we did not need the URL, that made the idea more palatable. I agree
> that support for comparing with branches will need to be improved. I just
> eventually realized that it is a separate issue to this one, and no matter
> how we implement this feature it is not going to solve the branch issue.
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.
regards,
Eugene
Received on Tue Dec 6 03:55:45 2005