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

Re: missing feature in Subversion: $Format keyword a la PRCS

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-12-23 19:06:58 CET

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
Received on Thu Dec 23 19:08:18 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.