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
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sun Dec 4 06:32:54 2005