Eugene Kuleshov <eu@md.pp.ru> wrote on 12/04/2005 11:57:34 PM:
> I see few weaknesses in your proposal.
I assume you mean that you "see "A" few weaknesses"?
> -- 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. 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.
> -- 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).
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?
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.
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.
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.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Dec 6 01:10:07 2005