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

Re: Feature request.

From: Serge Tumanyan <tumanyan_at_mail.ru>
Date: Mon, 16 Nov 2015 22:41:03 +0300

Hello, Stefan.

So the priority order of the properties would be:
for normal commits, and

for creating a branch.

In my workflow it does not matter if bugtraq:message has lower or higher
priority over bugtraq:messagebranch because trunk does not have
bugtraq:message over it.

But I see a problem here: by automatically specifying whether a ticket
is fixed/accepted/whatever you can not change that manually.
For such integrations with bugtrackers I recommend using the
bugtraq:logregex properties instead. That way users have to write the
'trigger' parts manually, but they can do so as needed and they actually
see what's happening to the ticket.

This is why I asked also for a disable checkbox in commit dialogue:
> In addition it would be great to have a checkbox that will allow to
> disable
> all these additions for exactly one revision for cases that are out of
> range
> and need not have this addition for some reason.

It may be just near a field for entering the bug number. And next to it in
tab order.
In my workflow over 95% is covered by requested modifications and in 5% of
the cases I can check the checkbox and not use this automatic addition to
commit message.

The reason why I do not want to use bugtraq:logregex is not only because I
do not want to type anything manyually, but also because if for some reason
I forget to do this nothing will stop commit. In case of the properties I
have requested (bugtraq:messagecommit, bugtraq:messagebranch) I can use
bugtraq:warnifnoissue and this will not allow me to commit without bug
number excluding the case when the 'Ignore bug track addition' will be

Thank you.



To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-11-16 20:45:19 CET

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.