Brock Janiczak <brockj_eclipse@ihug.com.au> wrote on 11/17/2004 05:47:17
AM:
> 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.
The configuration of the integration is based on properties. What I meant
was that the bug ID itself is not stored as a property. So you cannot
solve this problem by making property management fancier.
> >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.
Yes it is optional, however it is my contention that it is not reasonable
to push this burden completely to the bug ID vendor.
> >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).
There is a property that says if bug ID is numeric only. That would be
the only case where Subclipse would do any sort of validation of what was
entered. Anything else would be up to the bug vendor to provide in a
pre-commit hook.
> >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).
And then TortoiseSVN, ankhSVN, RapidSVN, PySVN, SCPlugin all have to
provide something similar and the bug ID vendor has to write all of those
integrations.
> >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...)
You do what Tortoise did. You hard code all of the ones that are used by
Subversion itself. It also includes the bug tracking properties as we are
trying to promote thise as a "Subversion standard" and finally it
hard-codes some others that it uses itself.
> 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'.
No, we use them in our own plugins all the time. It is definitely extra
work, but it is a nice way to solve the problem of letting two plugins
work together without being dependent on each other. I am not against
this, I was just wondering if there were any 3rd party plugins that had
expressed an interest.
> >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.
What are "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)?
The Tortoise developer wanted to use properties because you can discover
them in the WC without hitting the server. The properties have to be
present. He traverses up the hierarchy until he finds them. He also does
this in his repo browser. To answer your question, you would have to
commit the prop changes on the branch.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Nov 18 12:53:19 2004