also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.11.13.1109 +0100]:
> OK, but note that there are drawbacks. For example if we go for
> "(Git:af14e5)" that would be annoying, as parsing will depend on the
> number of supported, or "known", VCS. That was a wrong design choice
> of Vcs-* which I don't want to repeat.

I am not sure I agree. Maybe in the context of debian/control, but
I don't see the shortcomings for what we're trying to do.

Let's assume we copy the same scheme as Closes, meaning that
/[cC]loses:\s*(#?\d{6,}(,\s*#?\d{6,})*)/ yields the list of bugs in
$1, then we ought to have something similar for VCS commits.

But instead of one parser, I'd really rather think of it as a number
of parsers, each getting a chance. So Closes would be handled by the
dak-bts parser, and Git: by a git parser, SVN: by an SVN parser,

So, in any context, there will be a set of parsers, and when we
encounter Bazaar: but there is no Bazaar parser (assuming that...),
then a "Commit:Bazaar:" would not provide use with any more
information, really: we still couldn't parse it, even though
a generic Commit: parser might get a chance to. Yet, as you said,
the generic Commit: parser would not have knowledge about each VCS
(which I think is the design error you mention), so the benefit
would stay 0.

 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'` -
  `-  Debian - when you have better things to do than fixing systems
"most people become bankrupt through having invested too heavily in
 the prose of life. to have ruined one's self over poetry is an
                                                        -- oscar wilde

Attachment: digital_signature_gpg.asc
Description: Digital signature (see

vcs-pkg-discuss mailing list

Reply via email to