You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Matthieu Brouillard <ma...@agfa.com> on 2008/09/10 08:02:29 UTC

[PROPOSAL] Expansion keywords/properties enhancement

Hi all,

regarding the answers I had on the previous 
http://www.nabble.com/Automatic-replacement-on-commit-td19374972.html thread 
I posted regarding keyword expansion I would like to open a request for
enhancement.

My proposal is that it would be nice to have one of the two following
solutions implemented in future releases.

1/ keyword definition/expansion by third party tool:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - 
With some kind of plugin/contribution mechanism, it would be possible to
handle owner keywords. You will then be able to commit file like this:

### start of file ###
...
$Author$
$MyKeyword$
...
### end of file ###

that will be expanded to:

### start of file ###
...
$Author: Matthieu Brouillard$
$MyKeyword: SomeProvidedOrCalculatedValue$
...
### end of file ###

2/ Usage of properties in the keyword expansion mechanism
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
As properties are versionned in the same way the files are, it should be
possible to use some keyword extended syntax to access properties values in
the file content.

### start of file ###
...
$Author$               // No particular syntax => fecth standard property
svn:keywords
$Rev$
...
$prop:MyProperty$   // extended syntax to access properties
$prop:copyright$
...
### end of file ###

Perhaps there should be some rules/ban on the usage of standard subversion
properties and on unversioned properties.

What do you think of the propsal?

Thanks for your sharing.

Matthieu Brouillard

-- 
View this message in context: http://www.nabble.com/-PROPOSAL--Expansion-keywords-properties-enhancement-tp19408635p19408635.html
Sent from the Subversion Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by Matthieu Brouillard <ma...@agfa.com>.

David Weintraub wrote:
> 
> I've been following this conversation for a while, but I personally
> haven't found much use for keyword expansion because almost all of the
> information I need is actually available inside Subversion. In fact,
> most version control systems no longer to even bother with keyword
> expansion.
> 
> I also like the fact that Subversion is smart enough not to store the
> expanded keywords in the repository. Otherwise, you'll have problems
> with diffs and merges finding conflicts where none exist.
> 
> I am not sure what you would like to do, but it appears you want this
> information available once the program leaves the confines of a
> Subversion working directory and repository and is placed on a
> customer site. That way, version information is readily available when
> the client has some sort of problem.
> 
> A better mechanism is to design something yourself at package or build
> time. For example, it isn't uncommon to have some sort of parameter
> (like "@VERSION@") sitting in a particular file, and have this
> parameter replaced by the build number some sort of version ID, or the
> Subversion repository number when an actual build or packaging takes
> place. In fact, there is the "svnversion" command that is used
> specifically for this purpose.
> 
> You can easily do this for "copyright" and probably have it calculated
> at package/build time, so no one really has to maintain it.
I have no problem to put some replacement at build/deliver time for
replacements that are the same for each files; for example copyright is the
same for all the files and can be replace at build time.

But my need is that each file, once it is commited, gets a new version
(generated by some algorithm). We use this mechanism for database objects
and for auto-update mechanism on the client site.

As I said before, i am not blocked by not having such a feature. 
I will install a double commit mechanism using hooks. My though was just
that if an expansion mechanism already exists in subversion, why not
extending it. The "only" need would be to be able to contribute to meta-data
with an external/plugin/contribution mechanism.

Thanks for your thoughts, I will put in place the double commit mechanism.

-- 
View this message in context: http://www.nabble.com/-PROPOSAL--Expansion-keywords-properties-enhancement-tp19408635p19439001.html
Sent from the Subversion Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by David Weintraub <qa...@gmail.com>.
I've been following this conversation for a while, but I personally
haven't found much use for keyword expansion because almost all of the
information I need is actually available inside Subversion. In fact,
most version control systems no longer to even bother with keyword
expansion.

I also like the fact that Subversion is smart enough not to store the
expanded keywords in the repository. Otherwise, you'll have problems
with diffs and merges finding conflicts where none exist.

I am not sure what you would like to do, but it appears you want this
information available once the program leaves the confines of a
Subversion working directory and repository and is placed on a
customer site. That way, version information is readily available when
the client has some sort of problem.

A better mechanism is to design something yourself at package or build
time. For example, it isn't uncommon to have some sort of parameter
(like "@VERSION@") sitting in a particular file, and have this
parameter replaced by the build number some sort of version ID, or the
Subversion repository number when an actual build or packaging takes
place. In fact, there is the "svnversion" command that is used
specifically for this purpose.

You can easily do this for "copyright" and probably have it calculated
at package/build time, so no one really has to maintain it.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by Matthieu Brouillard <ma...@agfa.com>.


John Peacock-4 wrote:
> 
> Matthieu Brouillard wrote:
>> OK they are expanded on the client, but the value extracted by the client
>> side is stored on the server side, am I wrong?
> 
> No, the server only has the unexpanded form of the keyword stored.  Only
> the 
> client can expand the keyword and there isn't any mechanism to get
> additional 
> value/keywords from the server, nor is there any mechanism for the server
> to 
> generate them (modulo the existing hook structure).  All existing keywords
> are 
> processed exclusively on the client, using values that already exist in
> the 
> working copy metadata.   This is important because you need to be able to
> do 
> things like revert without contacting the server.

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by John Peacock <jo...@havurah-software.org>.
Matthieu Brouillard wrote:
> OK they are expanded on the client, but the value extracted by the client
> side is stored on the server side, am I wrong?

No, the server only has the unexpanded form of the keyword stored.  Only the 
client can expand the keyword and there isn't any mechanism to get additional 
value/keywords from the server, nor is there any mechanism for the server to 
generate them (modulo the existing hook structure).  All existing keywords are 
processed exclusively on the client, using values that already exist in the 
working copy metadata.   This is important because you need to be able to do 
things like revert without contacting the server.

> I agree that can be done in another way. But this introduce that I need to
> do it in my build/deliver process.
> For exemple, for the copyright I can use in my headers some markup like
> #COPYRIGHT# and then when I deliver my application I introduce a string
> replacement with some copyright value.
> Ok, this can be done like this but it should also have been handle by SVN
> that has already such a mechanism with the keyword expansion.

I actually crafted a patch to implement properties-as-keywords, but in the 
course of discussing it, it really didn't make sense, for exactly the reasons 
that Ryan discussed.  Without a way to manage inherited properties (which are 
set once and apply to multiple files), you wind up duplicating the property to 
every file which needs to contain that keyword, which just offloads the text 
into the relatively inefficient keyword handling.

Besides, no keyword can be more than a single line, with the current 
implementation, yet a build-time process can jam as much text into a 
substitution as you want.  There just isn't any gain to making Subversion to 
this work.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by Matthieu Brouillard <ma...@agfa.com>.
Hi,

Ryan Schmidt-42 wrote:
> 
> Keywords are only expanded in the client, not in the server. So to  
> implement custom keywords, you would probably need to have a script  
> which the client would run to compute the value of your new keyword  
> so it could be expanded. However Subversion has no client-side script- 
> running mechanism, and the Subversion developers have strong security- 
> related motivations for not providing client-side script-running  
> abilities.
> 
OK they are expanded on the client, but the value extracted by the client
side is stored on the server side, am I wrong?
For example the version of a file is not calculated by the client, it is
stored somehow on the server, and the client only access the value of this
Rev keyword.

In my mind, the extension mechanism consisted in having external programs
(plugins, extension, ...) that store additional values/keywords on the
server. Then client will not calculate anything, they will only ask the
value to the server. 
I really don't know the internal of subversion, it was just some guess &
ideas.

Let's take an example, in my file I want something like this:
$ObjectAppVersion: 4.3$
I need to generate a different ObjectAppVersion each time I commit a file.
The generation can be quite complex depending on the branch and other
parameters, so I cannot use the standard Rev keyword.
I would have liked to use some plugin/extension to handle this on the server
side.
Otherwise, I need to put in place, like I was saying in the previous thread,
some double commit mechanism with an automatic modification before the
second commit.


Ryan Schmidt-42 wrote:
> Let's take your example of $prop:copyright$ -- if you want the  
> copyright to appear in the contents of the file, why not just put it  
> into the contents of the file instead of putting it into a property  
> of the file and then trying to include it via some new mechanism?
I agree that can be done in another way. But this introduce that I need to
do it in my build/deliver process.
For exemple, for the copyright I can use in my headers some markup like
#COPYRIGHT# and then when I deliver my application I introduce a string
replacement with some copyright value.
Ok, this can be done like this but it should also have been handle by SVN
that has already such a mechanism with the keyword expansion.

Matthieu BROUILLARD

-- 
View this message in context: http://www.nabble.com/-PROPOSAL--Expansion-keywords-properties-enhancement-tp19408635p19430940.html
Sent from the Subversion Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [PROPOSAL] Expansion keywords/properties enhancement

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 10, 2008, at 03:02, Matthieu Brouillard wrote:

> regarding the answers I had on the previous
> http://www.nabble.com/Automatic-replacement-on-commit- 
> td19374972.html thread
> I posted regarding keyword expansion I would like to open a request  
> for
> enhancement.
>
> My proposal is that it would be nice to have one of the two following
> solutions implemented in future releases.
>
> 1/ keyword definition/expansion by third party tool:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> With some kind of plugin/contribution mechanism, it would be  
> possible to
> handle owner keywords. You will then be able to commit file like this:
>
> ### start of file ###
> ...
> $Author$
> $MyKeyword$
> ...
> ### end of file ###
>
> that will be expanded to:
>
> ### start of file ###
> ...
> $Author: Matthieu Brouillard$
> $MyKeyword: SomeProvidedOrCalculatedValue$
> ...
> ### end of file ###

Keywords are only expanded in the client, not in the server. So to  
implement custom keywords, you would probably need to have a script  
which the client would run to compute the value of your new keyword  
so it could be expanded. However Subversion has no client-side script- 
running mechanism, and the Subversion developers have strong security- 
related motivations for not providing client-side script-running  
abilities.


> 2/ Usage of properties in the keyword expansion mechanism
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> As properties are versionned in the same way the files are, it  
> should be
> possible to use some keyword extended syntax to access properties  
> values in
> the file content.
>
> ### start of file ###
> ...
> $Author$               // No particular syntax => fecth standard  
> property
> svn:keywords
> $Rev$
> ...
> $prop:MyProperty$   // extended syntax to access properties
> $prop:copyright$
> ...
> ### end of file ###

It probably could be done but I doubt it would be a high priority to  
implement it. Would it be particularly useful to you?

Let's take your example of $prop:copyright$ -- if you want the  
copyright to appear in the contents of the file, why not just put it  
into the contents of the file instead of putting it into a property  
of the file and then trying to include it via some new mechanism?


> Perhaps there should be some rules/ban on the usage of standard  
> subversion
> properties and on unversioned properties.
>
> What do you think of the propsal?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org