Brock Janiczak <brockj_eclipse@ihug.com.au> wrote on 11/21/2004 02:36:01
AM:
> Ok, i have finally got a chance to read the bugtraq integration
document.
>
> It just sounds like an overly fancy way of populating the commit message
> (for this one case only). Sort of like a pluggable commit dialog, but
> with no *real* bug tracker integration. For instance, you can't
> automatically resolve the issue post commit, or add a comment to the
bug.
The goal was to provide a better UI to improve the user experience. Also,
by assuming some control of the log message formatting, it enforces
consistency making it easier for the bug tracking vendor to write their
hooks. It was always a given for us that the bug tracking vendor had to
provide the hooks, we just wanted to provide a rich UI.
The Tortoise integration in their Show Log is really nice. I could make
up some screen shots and send them to you if you would like. This is a
critical feature for us in Subclipse, so we will be implementing it. We
just though since not everyone cares about it we would start by
contributing some general features, like the new commit dialog, which
everyone wants. We have an implementation of switch almost ready to
check-in as well.
> A simpler solution would have been to provide a customizable commit
> template. CVS does this using an rcsinfo file on the server. Of
> course, this would require a change to SVN itself, but it would be a
> generally useful thing to have (not just for bug tracking). You
> wouldn't have to retrieve the template each time you check out. It
> could be copied into the admin area when the checkout is performed (like
> CVS). Also, if you are going to be checking in, chances are you have a
> network connection available. Another cople of byte isn't going to kill
> anyone (compared to transmitting file contents).
>
> Does anyone other than Tortiose support these properties at the moment?
> Most importantly, does the standard command line client support them?
> By the way, I am in no way suggesting that we *shouldn't* support them.
We made some feelers to the svn dev's when we started this and it was
fairly clear that they would not be adding anything to the command line
that would help. In my opinion, and some others shared it, versioned
properties were not appropriate for this. For me, one big reason is that
the properties are "sticky". If you do modify the property on every
commit, then the previous value comes forward with each revision. Revision
properties are the most appropriate place for this information, but the
API support for revision properties is not very good for ad-hoc
properties. So ultimately, we decided to stick with the log message since
that is how most bug trackers were already doing it. It also makes it
relatively easy for the command line and other non-integrated clients to
participate in the process. Especially if someone sticks a pre-commit
validation hook in the process.
> >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.
>
> I never intended to make property management 'fancier'. I merely wanted
> a way to be able to present the user with a list (or tree) of registered
> properties to aviod typos and to hint what each proeprty is for. If a
> user wished to create a user defined proeprty for recording the last bug
> number that affected the file, they can do that. Recording the bug
> number a change was for could be useful, as it means you don't have to
> parse the commit message to find it (remember properties are versioned
> too). Obviously, the user should also be able to enter an
> 'unregistered' properties too, they just don't get any meta information
> explaining what the property is for or any type checking, as is
> currently done.
Like I said, if you want to do this, I think it would be great.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Mon Nov 22 03:05:22 2004