SteveKing <steveking@gmx.ch> wrote on 10/27/2004 11:39:02 AM:
> Mark Phippard wrote:
>
> > I was re-reading some notes I had written down in the past, and here
is
> > another idea I had.
> >
> > Implement this feature using something like client-side hooks.
Perhaps,
> > to configure this, you set a property that defines a command-line
option
> > to execute, this would allow custom parms to be passed to the program
by
> > setting those parms in the property. Perhaps TSVN would always pass a
> > filename as the first parm, and it would be up to the program to
populate
> > that file?
>
> Client-side hooks are on my todo list. But that will take some time to
do.
>
> But such hooks would only return TRUE or FALSE, not interfere with in
> some way with an operation. Either allow or deny the operation and
> return an error when denied.
> TSVN would only pass the path to the working copy (or in case of
> multiple targets a list of paths) and the hook program would then have
> to do the checking itself.
I just used the term client-side hook as it is the best way to describe
the concept of calling an external function. I do not think this truly
falls into the realm of a hook. My main point was that using the
technique I described allows the implementation to be customized by the
bug tracking vendor but still allows Tortoise to provide a great
out-of-the-box implementation. If I were to redescribe my idea, it would
be that Tortoise has a built-in feature to provide a ticket selection
dialog whose contents is based on some temp file. The program that
generates the temp file would be externalized in a property, but Tortoise
would come with a default implementation that used the approach you
describe.
> > Anyway, to meet some of your other requirements, TSVN could simply
come
> > with a program that provides a default implementation. In other
words, a
> > program that hits a URL and populates the file. This would provide an
out
> > of the box solution for most situations, but still provide
flexibility.
> > Not all bug tracking tools use HTTP, and this would allow those tools
to
> > still integrate with this feature.
>
> I think it's easier for a tool to implement http than to ask all
> Subversion clients to implement SOAP or worse each proprietary protocol
> for each bugtracking system out there.
I agree. What I really meant to recommend was a simple REST based
approach. This is basically what you are proposing already. Here are
some decent links:
http://www.xfront.com/REST-Web-Services.html
http://www.nwfusion.com/ee/2003/eerest.html
http://www.osmoticweb.com/rest-web-service-demo.htm
> > %BUG_LIST% would be a temp file that TSVN asks the program to write
the
> > results to. You could probably define a custom-formatted file,
presumably
> > XML, that the provider would have to create. When hitting the URL, it
> > would be expected that the contents of that file would just be
returned to
> > your program to write.
>
> If you drop the XML format, we can talk about this. Don't forget that
> C++ doesn't come with an XML library.
> (yes, I know there are such libs available, even for free. But
> increasing the size of the TSVN installer just for this?)
I am not married to XML, however, you do already have an XML parser
available in APR so you are already including one! I would be happy with a
simple name=value type approach. That aspect doesn't matter to me. The
nice thing about XML is that you can run it through an off-the-shelf
validator and discard invalid results easier.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 27 18:58:00 2004