[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] bugtraq feature extension

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-02-22 22:42:52 CET

Mark Phippard wrote:

>> Parsing a html file to find the issues is something that's not
>> possible in a way it would work with all issue trackers out there.
>> And it would be much more work and be error prone. The well defined
>> XML file is much better here.
>
> I do not disagree. I thought you were going to have properties for
> the RegEx that would do it. Since it is a property, you would just
> have to supply a working RegEx. I do not really understand RegEx
> enough to know if it is even possible. Also, I am not suggesting you
> do this, it is what I thought YOU were suggesting.

You'd think I've learned to express myself more clear by now, but
obviously I haven't ;)

> I think you are nuts on this one. When is the last time tigris.org
> updated anything? SourceForge usually isn't very quick to update
> either. I think if you did not have some kind if direct control over
> the server, odds are you would NEVER see this feature added.

You already need direct control over the server to add the pre-commit
hook scripts which associate the commit with an issue. So tigris.org or
even SF (which still doesn't support Subversion btw) wouldn't work anyway.
And generating the XML file is much easier than provide the hook script
and make the issue tracker tie the commit to an issue.

> In my opinion, the key is that the client you call ought to provide
> all of the UI and TSVN should just wait for the process to end and
> read what the user selected from a temp file that the client writes
> to. A browser app could even do this using an Applet or ActiveX if
> the user is dumb enough to let it.

Starting this in a separate process has the advantage that if the server
isn't available or very slow the commit dialog isn't blocked, i.e. the
user could still commit without waiting for the issue list to be fetched.

> The other way to do this would be
> for the client you call have to produce the complete XML file and you
> then read it and present the UI. Actually, I guess technically either

If we do that, then the client script would have to produce the XML file.

> way could work fine. I was just thinking that since authentication
> will still be an issue, it would be better if the "Select UI" were
> its own user-initiated dialog. That way any login prompts the client
> has to supply are more predictable.

But if the client script/program shows the UI with all the issues, we
would need some kind of IPC to make TSVN know the issue the user clicked
on...

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 22 22:44:12 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.