You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Basile STARYNKEVITCH <ba...@starynkevitch.net> on 2004/12/23 17:28:15 UTC
missing feature in Subversion: $Format keyword a la PRCS
Dear All,
I miss a feature in svn which is available in PRCS. The Format
keyword. From PRCS documentation on
http://voxel.dl.sourceforge.net/sourceforge/prcs/prcs_doc.html or
http://ovh.dl.sourceforge.net/sourceforge/prcs/prcs_doc.html (or other
Sourceforge mirrors).
Sometimes, you want keyword replacement data to appear without the
leading $keyword: and trailing `$'. A formatted keyword instance
allows this. An appearance in your file of
$Format: "string"$
string
will cause prcs checkin to replace the next line of the source file
(i.e., the line after the second `$') with string, after first making
modified keyword substitutions in it. Specifically, each instance of
$keyword$ in string (for which keyword is one of the recognized
keywords) is replaced by just the data that would be placed to the
right of the `:' in a simple keyword instance. The Format instance
itself is not altered--only the subsequent line. For example, if a
file in a project contains
/* $Format: "static char* version = \"$ProjectVersion$\";"$ */
static char* version = "x.x";
then the version of the file checked in for version 1.2 of the project
will contain
/* $Format: "static char* version = \"$ProjectVersion$\";"$ */
static char* version = "1.2";
The format string may not contain newlines. It may contain quotation
marks if they are stropped with a backslash, as in the example
above. In general, the backslash quotes the succeeding character. Any
keyword instances on a list after a Format instance are ignored (that
is, they are left unchanged by keyword substitution). Any nested
instance of Format is also left unchanged.
I find this feature extremely useful, for usage like above (or eg in
Makefiles, where some make targets depends upon the version, or the
date, etc....)
Do other people miss such a feature? Any clues on where it should be
implemented in subversion sources?
I might perhaps propose a patch for this, if there are some chances
it could be accepted. I don't know very well about Subversion social
developmment process. Could such a feature be included? How are
enhancement included in SVN (this is more a social question than a
technical one...).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: missing feature in Subversion: $Format keyword a la PRCS
Posted by Max Bowsher <ma...@ukf.net>.
Greg Hudson wrote:
> On Thu, 2004-12-23 at 12:28, Basile STARYNKEVITCH wrote:
>> /* $Format: "static char* version = \"$ProjectVersion$\";"$ */
>> static char* version = "x.x";
>
> An interesting idea.
>
>> Do other people miss such a feature? Any clues on where it should be
>> implemented in subversion sources?
>
> Well, I kind of doubt any of us is going to jump up and implement it
> right away. But neither do I think one of us would be likely to veto
> it. (This is just my gut feeling; obviously, every developer gets to
> speak for themselves.)
>
> One concern is that it's often possible to do the same sort of things in
> other ways, e.g. by storing the expansion of $Version$ in the string and
> then parsing out the version number in the code. That's maybe not as
> elegant from the source code's point of view, but we have traditionally
> avoided having a lot of redundant overlapping features for the sake of
> making little fiddly things like this easier.
>
>> I might perhaps propose a patch for this, if there are some chances
>> it could be accepted. I don't know very well about Subversion social
>> developmment process. Could such a feature be included? How are
>> enhancement included in SVN (this is more a social question than a
>> technical one...).
>
> Here's how it works:
>
> * Assuming none of us is motivated to implement it ourselves, you'd
> need to write the patch. Read HACKING; it's not a short document, but
> almost everything in there is important. The sections on coding
> guidelines and the section on writing log messages are particularly
> key. You would be modifying svn_subst_translate_stream() in
> subversion/libsvn_subr/subst.c.
>
> * You would submit the patch to the dev list, with a subject line
> beginning with "[PATCH] ".
>
> * Ideally, a developer (probably not me, alas) would decide that the
> feature is worthwhile enough to warrant reviewing the patch and
> committing it. The review might uncover problems, of course, which
> might necessitate further revs of the patch. If no developer jumps up
> immediately, our patch manager would file an enhancement issue in our
> issue tracker and we might reconsider it at a later date.
>
> * Any developer would be allowed to veto the change for technical
> reasons. If the patch doubles the size of subst.c dealing with nitty
> little quoting issues in the format strings, or turns
> svn_subst_translate_stream() into awful spaghetti, that might attract a
> veto.
>
> So, there is some chance the change would be accepted, but there's also
> some chance you'd put in 10-20 hours of work and it would languish in
> our issue tracker, or be rejected.
>
> I hope that answers your question. We do encourage contributions (with
> the exception of the project's founders, we all got here by making
> enough contributions ourselves to be offered commit access), but we also
> pride ourselves on having a mostly high-quality code base, so there is a
> certain amount of inertia for newcomers to overcome in order to add a
> new feature.
I second everything Greg said above, and add the following:
To avoid doing lots of work in vain, you can:
- First, design and discuss a complete specification of *exactly* how the
new feature should behave.
- Then, post a rough sketch of how you think the code to implement it should
be structured, and get a committers to review that.
- Then, go ahead with the actual patch.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: missing feature in Subversion: $Format keyword a la PRCS
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> On Thu, 2004-12-23 at 12:28, Basile STARYNKEVITCH wrote:
>
>> /* $Format: "static char* version = \"$ProjectVersion$\";"$ */
>> static char* version = "x.x";
>
>
> An interesting idea.
>
Actually, I was going to respond to this message (but I had a server fan
fail and my DNS went away for a while). :(
I have been sheparding a patch (originally proposed by plasma) to change
keyword handling to use a hash instead of the current fixed struct. As
part of that patch, it introduces a printf-style formatting for
keywords, but didn't expose that to the user, basically something like
#define SVN_KEYWORD_ID_FORMAT "%b %d %a %r"
so defining $Id: $ in terms of basename, date, author, and rev. See
http://subversion.tigris.org/issues/show_bug.cgi?id=890
for more details.
One of the primary reason this change wasn't accepted was that it only
sets the groundwork for later features (like inherited properties and
user defined keywords). However, not having use PRCS, I was not aware
of the $Format $ keyword, which actually seems like the ideal way to
expose the above patch's core functionality.
I'll have to revisit the patch to see how hard it would be to implement
this...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: missing feature in Subversion: $Format keyword a la PRCS
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-12-23 at 12:28, Basile STARYNKEVITCH wrote:
> /* $Format: "static char* version = \"$ProjectVersion$\";"$ */
> static char* version = "x.x";
An interesting idea.
> Do other people miss such a feature? Any clues on where it should be
> implemented in subversion sources?
Well, I kind of doubt any of us is going to jump up and implement it
right away. But neither do I think one of us would be likely to veto
it. (This is just my gut feeling; obviously, every developer gets to
speak for themselves.)
One concern is that it's often possible to do the same sort of things in
other ways, e.g. by storing the expansion of $Version$ in the string and
then parsing out the version number in the code. That's maybe not as
elegant from the source code's point of view, but we have traditionally
avoided having a lot of redundant overlapping features for the sake of
making little fiddly things like this easier.
> I might perhaps propose a patch for this, if there are some chances
> it could be accepted. I don't know very well about Subversion social
> developmment process. Could such a feature be included? How are
> enhancement included in SVN (this is more a social question than a
> technical one...).
Here's how it works:
* Assuming none of us is motivated to implement it ourselves, you'd
need to write the patch. Read HACKING; it's not a short document, but
almost everything in there is important. The sections on coding
guidelines and the section on writing log messages are particularly
key. You would be modifying svn_subst_translate_stream() in
subversion/libsvn_subr/subst.c.
* You would submit the patch to the dev list, with a subject line
beginning with "[PATCH] ".
* Ideally, a developer (probably not me, alas) would decide that the
feature is worthwhile enough to warrant reviewing the patch and
committing it. The review might uncover problems, of course, which
might necessitate further revs of the patch. If no developer jumps up
immediately, our patch manager would file an enhancement issue in our
issue tracker and we might reconsider it at a later date.
* Any developer would be allowed to veto the change for technical
reasons. If the patch doubles the size of subst.c dealing with nitty
little quoting issues in the format strings, or turns
svn_subst_translate_stream() into awful spaghetti, that might attract a
veto.
So, there is some chance the change would be accepted, but there's also
some chance you'd put in 10-20 hours of work and it would languish in
our issue tracker, or be rejected.
I hope that answers your question. We do encourage contributions (with
the exception of the project's founders, we all got here by making
enough contributions ourselves to be offered commit access), but we also
pride ourselves on having a mostly high-quality code base, so there is a
certain amount of inertia for newcomers to overcome in order to add a
new feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org