> -----Original Message-----
> From: Stefan [mailto:luke1410_at_gmx.de]
> Sent: dinsdag 11 februari 2014 22:07
> To: users_at_subversion.apache.org
> Subject: how to use one bug ID syntax for two different butracking-pools
>
> Hi,
>
> I'm not sure whether TSVN mailing list would be more appropriate for the
> actual use-case-related part of the question. Hence I'm trying to keep
> it more SVN-specific:
>
> Is there a way in SVN to perform some kind of bulk-changes or
> replace-operation on all committed log-messages?
> What I have in mind is replacing all occurrances in all log messages of
> the style \#(\d+) with XT\-($1) where $1 is the captured number in the
> previous string and the \d would represent a number-value.
> In other words:
> "Foo #2354."
> Should become:
> "Foo XT-2354."
>
> The only idea I get here is to perform a dump/load-cycle and before the
> load, perform a regexp-replacement on the dump-file.
> Anybody has a better solution?
>
> Underlying usecase (maybe someone else comes up with a better solution
> for the actual issue):
> We make use of TSVN's bugtraq-properties (see:
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-
> bugtracker.html).
> Up to now we used the syntax: "#XXXX" which then corresponded to issue
> number XXXX and refrenced a link to: http://foo.com/bar.php?query=XT-
> XXXX.
> XT is a unique-ID in the bugtracker.
>
> Now we moved to use two separate projects in the bugtracker, both
> relying on the same code base. The assigned unique IDs are XT- and XR-.
> All existing IDs used XT-, while all new ones will use the XR-. The
> expectation for commits in the future are that these will only reference
> XR-prefixes.
>
> In a perfect world, I'd like developers to offer two ways to write their
> ID-references:
> - use the #XXXX-syntax, which will then default to XR-XXXX
> - use either XT-XXXX or XR-XXXX syntaxes, if they want to explicitly
> reference either an issue for XT or XR.
> All existing syntaxes of #XXXX should of course still use the
> XT-XXXX-references.
>
> My problem is that the bugtraq-properties only support a single regexp
> to extract the actual relevant bug-message and then from that extract
> the bugID which is then used to create the link to the bugtracker.
>
> So what I can do is:
> - enable the new XT-/XR-syntax OR (problem: the #-syntax won't work at
all)
> - change the #-syntax and make it refer the XR-issues (problem:
> XT-/XR-syntax is not possible, old #-issues will incorrectly reference
> the XR-issues (even though these were created for the XT-issues)
> - keep the #-syntax refere to the XT-issues (problem: XR-issues cannot
> be referenced)
> - allow the #, XT- and XR-syntax, pass it on to some wrapper CGI-script
> (aka: http://foo.com/customwrapper.cgi?query=#XXX|XT-XXX|XR-XXX) and
> let
> that CGI-script resolve the actual reference. (problem: hard to set-up
> in our environment, does result in inconsistent issue-naming in TSVN,
> since in one case the issue is #XXXX while in the other case issues are
> XT-XXXX or XR-XXXX).
>
> Any idea/suggestions on the best practice to approach this problem?
I think you can use the dual regex approach documented by TortoiseSVN to
make your Subversion clients (TortoiseSVN, Subclipse, AnkhSVN) match both
syntaxes.
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-bugtracker.html
In the past I installed the following regex combination:
(\b(([Ii]ssue\s*(:\s*)?[#]?)|#)\d+(\s*(,|and)\s+[#]?\d+)*)|(\b[A-Z][A-Z]+-\d
+)
(([A-Z][A-Z]+-)?\d+)
This detected plain issue numbers in many forms and also ZZZZ-2345 formats
where ZZZZ is just two or more capital letters (Jira syntax).
We used the custom cgi script approach to route the first format to the
legacy bugtracker one and all the others to Jira.
Note that the TortoiseSVN documentation says something about this format not
being recognized by some issue tracker with direct Subversion integration.
(Not sure which one)
Bert
>
> Regards,
> Stefan
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
Received on 2014-02-12 10:24:27 CET