Mark Phippard wrote:
> Cool. Just a few comments.
>
> 1) Weren't there some issues with using ':' property names? I thought
> they were discouraging using that for some reason. I think it has to do
> with sending them over DAV. I do think it was fixed though.
Don't think it was with the ':' but with the ';'. Subversion uses the
':' for all its own properties too. So if there were problems with that
then it would have caused problems very early in the dev process and
would also be more often reported on the mailing list there.
> 2) Could you explain more how you have integrated this into the history,
> such as log displays? For example, when does the URL come into play? Are
> you just parsing the log messages to get the bugID?
The log dialog shows the log message like before. But if those
properties are set on the working copy from where the log is started, it
parses each log message for the issue number as defined in the
properties. If it finds them, it will turn the issue number into a link
(showed underlined). If the user then clicks on that issue number in the
log message, the browser is started with the URL created from the
properties and the issue number.
if the URL property is defined as:
bugtraq:url = http://my.bugtracker.home/issue?id=%BUGID%
then the browser will open at
http://my.bugtracker.home/issue?id=1234
(if the issue number of the log message is 1234).
> 3) While I think your reasoning on revision properties is somewhat solid,
> I still see no reason not to add the feature, especially if it was off by
> default and required some properties to turn it on. The main reason for
> revision properties was that it seemed like it would make #2 easier to do
> consistently across clients. Perhaps that is not the case. I also think
> it would open the door someday to be able to query the repository by
> revision properties. Currently you cannot do this, but the idea has been
> floated as being desirable. In a SQL repository this would probably be
> easy to do.
The revision property would be used by the bug tracking tool only. I see
no use for that in a client. And it can easily be done by a post commit
hook - that's why I don't want it in the client. A post-commit-hook can
_assure_ that it works equally with all clients.
> 4) RegEx. I do not think it would be too huge a problem if there were
> inconsistencies as long as the way it worked was documented. I was
Not really. If a bug tracking tool uses a regexp which doesn't work
equally across all libraries, different Subversion clients then would
validate the issue number differently and maybe even not recognize them
at all and just reject any issue number entered.
> wondering whether there were libraries available though. I do not know
> RegEx very well myself, but I would assume that the RefEx to validate a bug
> ID would be fairly simple and likely to be consistent across
> implementations. Idle speculation though.
As long as there is no official standard defined for it, you can't be
sure. And speculations are too risky for something like this.
> 5) If not RegEx, another built in validation could be minimum and maximum
> characters.
Could be done. But I don't see that this would help a lot.
> 6) My Bug ID's can sometimes have embedded blanks. Will that be OK in
> your system? For example might be XYZ 0001.
Yes, sure. Just set the property
bugtraq:number to "false" - then any text is valid.
> I look forward to trying this, when do you think there will be a new build
> available with this in it?
Maybe we have a nightly build set up soon. The only problem not solved
yet is the server where to upload the automatic build. The tigris.org
server doesn't allow ftp access - and an automatic upload via http is
not possible there either.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Aug 21 21:16:06 2004