Hi Mark,
Please be aware while reading my response that i haven't read your issue
tracking integration document yet, so some of my responses may sound
ignorant :)
Mark Phippard wrote:
>Please read the spec again:
>
>
You assume i read it the first time :)
The Collabnet SVN server seems to be playing up so i will read though it
later.
>http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
>
>The goal is to make a common system that all svn "GUI's" could support so
>that there was some consistency across clients. Also, you seem to be
>operating under the misconception that the integration is based on
>properties. It does use properties, but only as a way of communicating
>configuration to the GUI.
>
How can the integration NOT be based off properties? You need at least
properties to define what type of bugtracking system you are using and
its location (unless you make each end user set it up...). My point was
that these properties (even the one for turning on the integration) are
not 'standard' SVN properties.
>In other words, the properties exist to "turn
>on" the integration in the GUI. Without the properties, the GUI would
>behave the same as it did before it added the integration.
>
>
That sounds like optional functionality to me. Not everyone uses bug
trackers. My philosophy is: "If i am not going to use it, i should have
to download it". The question is: is bug tracking a core part of
version control? I don't think so, but i could be wrong.
>There are two main UI elements to the integration when it is turned on:
>
>1) The commit dialog adds a field to collect Bug ID's associated with the
>commit. It then automatically adds this info into the commit message so
>that it is formatted consistently without requiring the user to type the
>info.
>
>
I am guessing the format is defined in a property somewhere. Not all
bug trackers use numeric fields (only sane ones do).
>2) The "svn log" UI in the GUI should parse the task ID's back out of the
>log messages and provide a UI for executing a URL to view the task ID.
>Tortoise does this by just turning the bug ID text into a hyperlink, but
>it could be done in any way that was appropriate for the UI.
>
>
This would indeed be cool.
>I do not see how either of these items could realistically be done by the
>bug ID vendor. It pretty much has to be part of the base GUI. That is
>why we defined the use of properties as a way of communicating the
>configuration to the GUI.
>
>
>
I can, assuming that the commit dialog can be extended or replaced in
some way. This is not possible with our current implementation, but it
wouldn't take much to do. If we allowed a bug tracker integration
plugin to add its own commit dialog they would have full control over
what fields are presented and how that data is converted into a commit
message. You would still have to use a pre commit script to make sure
everyone is using correctly formatted messages though (i don' think
there is any way around that).
>If you do not mind doing it, it is a good idea. However, at some point
>the list still has to be coded somewhere. You are just doing it more
>abstract. Personally, I would hard-code the known list of properties, and
>if we wanted to let a user define their own, there are a number of ways we
>could do it:
>
>
My point is that how do you know what the hard coded list is? You are
assuming that your list is definitive. The point of properties (i
thought) was to allow people to come up with new and crazy uses for
them. I only used bug tracking as an example. I am sure there are
others (not that i can think of any...)
Just curious. Do you think it is hard to define an extension point?
That was the first time i had ever written one and i didn't find it much
harder than defining it in an external file. Sure hard-coding is easy,
but it isn't really 'the eclipse way'.
>1) In Preferences, provide a page where the user could define property
>names. The negative here is that it would be machine specific, although
>preferences can be exported.
>
>
That is how i saw the user adding properties too. It was never my
intention to force them to write a plugin just to add some properties to
a tree (that would be stupid). That is what the empty
loadUserProperties method was for. I am not a fan of exporting
proeprties myself. It seems much nicer to use 'team' scoped preferences.
>2) We could do something similar to what we did in the bug tracking spec.
> Define a property name like "properties" whose value is a comma-delimited
>list of custom property names. The GUI would then "discover" this
>property in the WC and use it to populate the drop down. The advantage
>here is that since this is stored in the repository it gets pushed to the
>client when they checkout their WC.
>
>
>
Discovery sounds like a good idea. What do you do about properties
being versioned? I assume you take the one from teh current version.
What happens when you are working on an old branch (after you have
changed bug tracking systems)?
>I am using Eclipse 3.0.1, if it matters. The error is on line 61 of
>svnPropertyTypes.exsd. The text is: "Element "svnPropertyTypes",
>attribute "type": when "use" is "default", "value" must be set"
>
>
Thanks for that. It seems to be a bug in PDE. I have raised bug 78823
https://bugs.eclipse.org/bugs/show_bug.cgi?id=78823 for it. It wasn't
detecing most schema errors. Yet another bug in the schema editor!
Cheers,
Brock
Received on Wed Nov 17 21:47:17 2004