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