Mark,
I see few weaknesses in your proposal.
-- First of all I think you are underestimate importance of comparison
between branches. I do believe that comparison with static tags is too
restrictive.
-- 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.
So, I'd like to suggest to slightly change your approach to make it
less limiting.
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.
Thanks
Eugene
Mark Phippard wrote:
> I have been thinking about this request and can see the value that an easy
> solution can bring. Let me lay out there what I can realistically see
> doing and get some feedback. I will warn you right now, my main concern in
> tackling a feature like this is that due to the limitation in the design of
> Subversion, I do not think we can provide all of the features users want.
> I am concerned that if we try to solve part of the problem it will just
> constantly raise the other issues and we will either be forced to provide
> hack after hack, or just not do anything.
>
> This proposal really only tackles one area ... showing tag/alias
> information in the History view. This would provide a bit more information
> when browsing the history of a file and would make it easier to know what
> revisions of a file to compare when doing analysis. Finally, this
> information would likely only be available when browsing the history of
> files that are in your local working copy. If viewing history from the
> repository browser, this information would not be available.
>
> 1) When browsing the history of a local file, we would check all parent
> folders back to the project root for the presence of a Subversion property
> named: subclipse:tags. This property would contain information on revision
> numbers and tags/aliases like this:
>
> 110 REL1.0
> 184 REL1.1
> 241 REL2.0
> 300 REL2.5
>
> etc...
>
> Format would be revnum + whitespace + tag/alias + newline
>
> There could be any number of these pairs in the single property. If the
> properties are found in multiple parents they will be merged.
>
> 2) History view would have a Tags/Aliases column added to show the tags
> that apply to each revision of the file. Basically, you would be loading
> the history from highest revision to lowest and you would have an array of
> aliases. As you processed each revision you would pull out of the array
> the aliases that were greater than or equal to the revision of the item
> being looked at. A single revision might have more than one alias, but an
> alias could only apply to a single revision.
>
> Let's call up to here Milestone 1. At this point the main goal of the
> feature would be implemented.
>
> 3) Add a nice GUI editor for maintaining the property that would handle
> the details of parsing and rewriting the property. The editor would give
> basic CRUD functionality and also have a feature that lets you browse a URL
> and select a bunch of tag folders to create aliases. The tools would pull
> in the name of the tag folder and the last changed revision of the folder.
>
> This would be Milestone 2. Same basic feature, a bit easier to use.
>
> 4) Enhance the Create Branch/Tag action to have an option to add the tag
> that was just created to the property. This would mean the folder with the
> property would be modified after the tag was created and would have to be
> committed.
>
> This would be the Final Milestone. Feature would be fully implemented.
>
> Discussion Points:
>
> 1) Use of Subversion property for storing this information. This has a
> lot of advantages, namely that once someone configures the aliases, every
> user in the project gets the feature for free. Also, it means we do not
> have to write a lot of I/O routines for storing/retrieving the information.
>
> This also has downsides.
>
> Property changes have to be committed. I figure if you do not have commit
> rights to a project and/or enough clout to add the property to the
> repository, then you probably do not really need this feature that bad
> anyway. In projects that mostly use Subclipse, the Release Manager would
> probably just keep the property maintained as part of creating the tags.
>
> Properties are copied. So they will flow into branches and tags. Not
> necessarily a bad thing.
>
> Alternative would be to store the information locally in Eclipse .metadata.
>
> 2) Feature is fake. It is relying on the true concept of a tag. There is
> no knowledge of the tag location and compares are not done against the tag.
> Instead, it is based on the assumption that the version of the file that
> was copied into the tag is the final version in the tag. This is a fairly
> safe assumption, but it means the feature doesn't really do anything for
> branches.
>
> All in all, I feel pretty good about the idea. I think it is tackling an
> area that the Subversion developers do not have a lot of plans for. Most
> of the ideas they are pursuing would be hard to make use of in Subclipse,
> especially unless we get an ability to turn an svn diff into a graphical
> Eclipse compare.
>
> Please provide some feedback. I am working on a CVS-style Checkout wizard
> right now, and when that is done, I would like to look at this.
>
> Thanks
Received on Mon Dec 5 15:57:34 2005