You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Graeme Vetterlein <gr...@vetterlein.com> on 2008/03/24 21:31:22 UTC
svn:keywords ... a plea
OK, I've finally worked up enough enthusiasm to
put this down in text. (and register for mailing-list etc ...)
In case I get the mood wrong, this is a plea, not a rant. ... honest.
I guess I've been using Source code control systems on Unix type
platforms for 20-25 years. I've used SCCS, RCS, CVS, PCVS, Clearcase
and most recently SVN. I've used SVN at work for a couple of years and
I'm finally moving my home systems over to SVN.
One thing I've always impressed on people developing software is
VERSIONS:
1: Make sure you have them
2: Make sure people can identify them
For part2, I'm usually meaning things like -v (--version) and ident(1)
and what(1) strings. All these rely on version keywords. Simple:
SCCS: static const char sccid[] = "%Z%%M% %I% %E%"
RCS: static const char rcsid[] = "@(#)$Id:$";
CVS: static const char cvsid[] = "@(#)$Id:$";
+ edit the file: $CVSROOT/CVSROOT/cvswrappers to ensure binary files
have -kb (to avoid keyword expansion)
SVN: static const char svnid[] = "@(#)$Id:$";
Then either:
for each file:
svn propset svn:keywords "Date Author" weather.txt (from the
svnbook)
... but possibly you meant:
svn propset svn:keywords "Id Date Author" weather.txt
... but more than once I've typed:
svn propset svn:keywords Id,Date,Author weather.txt
Which works (as in , does not fail) but of course totally fails
to do the substitution.
... Or I might type:
svn propset svn:keywords "id date author" weather.txt
Again no error, but no substitution either.
So what do I find. Most (SVN) files do not have the keywords
substitution turned on. So when trouble hits and you type "ident
broken-prog" you get very little help back. Typically just the library
code that was in rcs or cvs.
So I decide. Enough is enough. I'm going to set the correct option of
the SVN repository I creating at home to ensure I (at least) don't
have this problem. I consult the svn book:
I read it and find:
Auto-prop support is perhaps the handiest property related
tool in the Subversion toolbox. See the section called
"Config" for more about configuring that support.
...sounds good, so I follow on:
enable-auto-props
This instructs Subversion to automatically set properties on
newly added or imported files. The default value is no, so set
this to yes to enable Auto-props. The auto-props section of
this file specifies which properties are to be set on which
files.
...not quite what I would like, but OK. bit like -kb in cvs wrappers
I'll just setup my repository to add this to all files. Can't seem to
find the right file, go back and re-read the section and discover this
is a CLIENT-SIDE config setting ...What! OK , get a grip, hard to work
out why a project specific setting should be governed by a config file
that depends on the (1st) user who updated the file?
I stay cool and read on:
The auto-props section controls the Subversion client's ability to
automatically set properties on files when they are added or
imported. It contains any number of key-value pairs in the format
PATTERN = PROPNAME=PROPVALUE where PATTERN is a file pattern that
matches a set of filenames and the rest of the line is the property
and its value. Multiple matches on a file will result in multiple
propsets for that file; however, there is no guarantee that auto-props
will be applied in the order in which they are listed in the config
file, so you can't have one rule "override" another. You can find
several examples of auto-props usage in the config file. Lastly, don't
forget to set enable-auto-props to yes in the miscellany section if
you want to enable auto-props.
So there is an "auto-props section" ... bound to be a description of
that in the book ... nope, never comes up again, I wonder what an
"auto-props" section looks like. Ahh there's the answer:
"You can find several examples of auto-props usage in the
config file"
... can you heck :-) There is no mention of the "auto-props section"
anywhere (that I can find) other than that lone paragraph in the
svn-book. Still know I know the magic keyword I can unleash google on
it. I discover the apache 'svn config file'
http://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html
Finally ... the answer!!
In summary:
1: Adding keywords is (almost) always a GOOD IDEA ... just need to
take care in a few cases
2: Getting keywords to work in most version control systems is simple
3: In SVN it is very hard:
i: Requires a special setting on each file
ii: Setting is 'free format' so cannot be syntax checked by svn
iii: Automatic setting of option cannot be done on repository
(i.e. project) basis
iv: Setting of option on client side:
a: Mostly missing from documentation
b: Not given default values in generated files (like many
other options)
4: Very few files I've found in SVN have the keywords set
(correctly) (this is MY experience ... many 10's of users)
This seems very like "Spoiling the ship for a hapenth of Tar".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/24, Ryan Schmidt <su...@ryandesign.com>:
>
> On Mar 24, 2008, at 16:31, Graeme Vetterlein wrote:
>
> > In summary:
> >
> > 1: Adding keywords is (almost) always a GOOD IDEA ... just need
> > to take care in a few cases
> > 2: Getting keywords to work in most version control systems is
> > simple
> > 3: In SVN it is very hard:
> > i: Requires a special setting on each file
> > ii: Setting is 'free format' so cannot be syntax checked by
> > svn
> > iii: Automatic setting of option cannot be done on
> > repository (i.e. project) basis
> > iv: Setting of option on client side:
> > a: Mostly missing from documentation
> > b: Not given default values in generated files (like
> > many other options)
> > 4: Very few files I've found in SVN have the keywords set
> > (correctly) (this is MY experience ... many 10's of users)
>
>
> I haven't used other version control systems so I don't know first-
> hand how Subversion's keyword handling compares.
>
> Yes, auto-props are a client-side config setting. But you can install
> a pre-commit hook on the repository to reject any commit that does
> not conform to your policy, be that policy of certain keywords on
> certain types of files or anything else. If you reject a commit, you
> can explain to the user why (on stderr) and even direct them to a pre-
> made config file somewhere on a server of yours that they can download.
>
> Make sure you do not define an auto-props rule like "* =
> svn:keywords=Id" (to set svn:keywords to Id on all files) because
> this would also apply to binary files, on which keywords are possibly
> inappropriate and could result in corruption and data loss. Set
> automatic properties only on filename extensions which are text
> files. (There are fixed-width keywords, however, which can be used
> probably safely, for example, in Word documents and some other binary
> formats which contain textual data.)
>
> I think svn could check the syntax of svn:keywords to ensure it's
> valid. It just doesn't. Again, you could check the syntax of
> svn:keywords in a pre-commit hook, and reject the commit if the
> syntax isn't valid.
>
> Book suggestions should be sent to the svnbook mailing list. See the
> bottom of http://www.svnbook.org/
The need to add hook scripts to check that a mandatory configuration
is done correctly implies that something is bad. Why should the same
comfiguration be specified both on client and server side (with
completely different syntax as well)?
We have a few different repositories and we use different keywords in
them (I don't want it to look like I've done changes in vendor drops,
therefore no keywords is set in the vendor repository. But the client
configuration is done per client, not per repository -> The hook
scripts will need to give responses like "Configure client to use
config file for repo3".
$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 24, 2008, at 16:31, Graeme Vetterlein wrote:
> In summary:
>
> 1: Adding keywords is (almost) always a GOOD IDEA ... just need
> to take care in a few cases
> 2: Getting keywords to work in most version control systems is
> simple
> 3: In SVN it is very hard:
> i: Requires a special setting on each file
> ii: Setting is 'free format' so cannot be syntax checked by
> svn
> iii: Automatic setting of option cannot be done on
> repository (i.e. project) basis
> iv: Setting of option on client side:
> a: Mostly missing from documentation
> b: Not given default values in generated files (like
> many other options)
> 4: Very few files I've found in SVN have the keywords set
> (correctly) (this is MY experience ... many 10's of users)
I haven't used other version control systems so I don't know first-
hand how Subversion's keyword handling compares.
Yes, auto-props are a client-side config setting. But you can install
a pre-commit hook on the repository to reject any commit that does
not conform to your policy, be that policy of certain keywords on
certain types of files or anything else. If you reject a commit, you
can explain to the user why (on stderr) and even direct them to a pre-
made config file somewhere on a server of yours that they can download.
Make sure you do not define an auto-props rule like "* =
svn:keywords=Id" (to set svn:keywords to Id on all files) because
this would also apply to binary files, on which keywords are possibly
inappropriate and could result in corruption and data loss. Set
automatic properties only on filename extensions which are text
files. (There are fixed-width keywords, however, which can be used
probably safely, for example, in Word documents and some other binary
formats which contain textual data.)
I think svn could check the syntax of svn:keywords to ensure it's
valid. It just doesn't. Again, you could check the syntax of
svn:keywords in a pre-commit hook, and reject the commit if the
syntax isn't valid.
Book suggestions should be sent to the svnbook mailing list. See the
bottom of http://www.svnbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Graeme Vetterlein <gr...@vetterlein.com>.
Peter,
> Thanks for the email. I went through exactly the same exercise last
> week and, like you, was stunned that auto-props was a client-side
> option AND that it was next to impossible to find good examples of
> this mysterious config file anywhere. At least I'm not alone.
>
No, I think a lot of folks hit this problem, some have only met one or two
version control systems or only done one style of development so have yet
to realise.
To clarify:
1: This is not a "theoretical comment" . Within the past year I have seen
many man-days lots trying (unsuccessfully) to work out what version of
a class was running in "the real world".
2: Just because 'you' can't see why a feature is needed is no excuse for
making it
hard to use.
3: There are many things that are version controlled , not just a
single executable
Let me give a few examples:
i: A 'static library' (i.e. foo.a) the object code in this finds it's
way into many executables (a.out).
When a a.out is found to be broken, it's obviously vital we can find
out what version of a given '.o'
is in the linked file. It's all very well that we put a (single)
revision number in our archive, but we can't
complain when the customer reports that foo_method1() is broken and
sends you his linked edited program.
(HE might not have well controlled build process)
ii: A .jar file containing a set of utilities , which worked when we
shipped it, but somebody has misapplied a patch
because the checksum has changed ... but which class file has been
affected?
iii: The one I really like doing:
# ident /proc/2805/exe
/proc/2805/exe:
$Id: res_mkupdate.c,v 1.7.2.3 2004/06/10 17:59:43 dhankins Exp $
$Id: res_update.c,v 1.11.2.3 2004/06/10 17:59:44 dhankins Exp $
$Id: res_findzonecut.c,v 1.14.2.4 2004/06/10 17:59:43 dhankins Exp $
$Id: ns_parse.c,v 1.2.2.2 2004/06/10 17:59:40 dhankins Exp $
$Id: ns_sign.c,v 1.4.2.4 2004/06/10 17:59:42 dhankins Exp $
$Id: ns_name.c,v 1.1.2.5 2004/06/10 17:59:40 dhankins Exp $
$Id: ns_samedomain.c,v 1.3.2.4 2004/06/10 17:59:41 dhankins Exp $
$Id: ns_verify.c,v 1.5.2.3 2004/06/10 17:59:42 dhankins Exp $
$Header: /proj/cvs/prod/DHCP/dst/dst_api.c,v 1.1 2001/02/22
07:22:08 mellon Exp $
...goes on for a while
(this is dhcp3 , by the way)
This shows which versions of files are inside the text region of the
running code. This is REALLY useful
if the code has dynamically loaded .so or .class files. You can find out
what code DID get loaded ... then
you need to work out WHY.
iv: Things like document templates. Each template has a version, each
file produced from that template
need to inherit the version number.
v: Macros. The (users) code might not work because they macro-expand
(our) version1 code, then used the version2
product. They've since upgraded the macros to version2 ... but they
forgot to redo the macro-expand process ... we
need to find out what versions of (our) macros generated the code.
... lots and lots
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Peter Connolly <ps...@gmail.com>.
> I read it and find:
>
>
> Auto-prop support is perhaps the handiest property related
> tool in the Subversion toolbox. See the section called
> "Config" for more about configuring that support.
>
> ...sounds good, so I follow on:
>
> enable-auto-props
>
> This instructs Subversion to automatically set properties on
> newly added or imported files. The default value is no, so set
> this to yes to enable Auto-props. The auto-props section of
> this file specifies which properties are to be set on which
> files.
>
>
> ...not quite what I would like, but OK. bit like -kb in cvs wrappers
> I'll just setup my repository to add this to all files. Can't seem to
> find the right file, go back and re-read the section and discover this
> is a CLIENT-SIDE config setting ...What! OK , get a grip, hard to work
> out why a project specific setting should be governed by a config file
> that depends on the (1st) user who updated the file?
>
> I stay cool and read on:
>
> The auto-props section controls the Subversion client's ability to
> automatically set properties on files when they are added or
> imported. It contains any number of key-value pairs in the format
> PATTERN = PROPNAME=PROPVALUE where PATTERN is a file pattern that
> matches a set of filenames and the rest of the line is the property
> and its value. Multiple matches on a file will result in multiple
> propsets for that file; however, there is no guarantee that auto-props
> will be applied in the order in which they are listed in the config
> file, so you can't have one rule "override" another. You can find
> several examples of auto-props usage in the config file. Lastly, don't
> forget to set enable-auto-props to yes in the miscellany section if
> you want to enable auto-props.
>
>
> So there is an "auto-props section" ... bound to be a description of
> that in the book ... nope, never comes up again, I wonder what an
> "auto-props" section looks like. Ahh there's the answer:
>
> "You can find several examples of auto-props usage in the
> config file"
>
> ... can you heck :-) There is no mention of the "auto-props section"
> anywhere (that I can find) other than that lone paragraph in the
> svn-book. Still know I know the magic keyword I can unleash google on
> it. I discover the apache 'svn config file'
>
> http://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html
>
> Finally ... the answer!!
>
Thanks for the email. I went through exactly the same exercise last
week and, like you, was stunned that auto-props was a client-side
option AND that it was next to impossible to find good examples of
this mysterious config file anywhere. At least I'm not alone.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 25, 2008, at 05:20, marc gonzalez-carnicer wrote:
> the point is that with SVN, as well as with other *modern* VCSs, there
> is no need to track date, version and author of each file because
> every commit is a "freezepoint", and the yielded revision number is
> all you need, and the date, author, etc info is on the log.
And, to complete this thought, perhaps all you need is to record
"the" revision number of the source in the build:
http://subversion.tigris.org/faq.html#version-value-in-source
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
hi,
i don't quite understand the point of your email. you seem
to just make an informative comment to share. i am replying
because i've found it funny to find somebody else in this list
who has also used SCCS, which is what i used before i found
svn. and also, i'd like to point out that i find keywords in the
sense that you use them pretty useless (my opinion :)
2008/3/24, Graeme Vetterlein <gr...@vetterlein.com>:
> OK, I've finally worked up enough enthusiasm to
> put this down in text. (and register for mailing-list etc ...)
>
> In case I get the mood wrong, this is a plea, not a rant. ... honest.
>
> I guess I've been using Source code control systems on Unix type
> platforms for 20-25 years. I've used SCCS, RCS, CVS, PCVS, Clearcase
> and most recently SVN. I've used SVN at work for a couple of years and
> I'm finally moving my home systems over to SVN.
>
> One thing I've always impressed on people developing software is
> VERSIONS:
>
> 1: Make sure you have them
> 2: Make sure people can identify them
>
> For part2, I'm usually meaning things like -v (--version) and ident(1)
> and what(1) strings. All these rely on version keywords. Simple:
>
> SCCS: static const char sccid[] = "%Z%%M% %I% %E%"
hehe :) this line triggered many memories. btw, i think some
SCCS / teamware implementations had an error. whenever your
code contained some date string, like "2001/01/01", that could be
mistook by the sccsid string, that date was replaced by something
like "%Z...", and that caused the code not to work. it was pretty tough
to find out what happened because when the file were checked out,
the file was correct, but when checked in, it was not : so we finally decided
not to use sccsid.
but back to my point. i really don't understand why you need to
set these date and author properties / keywords : it is *all* in the
log.
i remember that we had the policy to set sccsid properly in all
our files in case a bug was found in the code, it was possible to know
which version of each file the executables had been produced from, with
the "strings <executable> | grep sccsid" command, and assuming
that the deployed executable had not been properly "freezepointed" (in
the SCCS sense).
the point is that with SVN, as well as with other *modern* VCSs, there
is no need to track date, version and author of each file because
every commit is a "freezepoint", and the yielded revision number is
all you need, and the date, author, etc info is on the log.
so, i am not gonna get into the details on how to set autoprops or
other things, just that i want to suggest that perhaps there is no
need to use them. but it that has been implemented i may be
missing something. my apologies if i misunderstood the point of
your email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:keywords ... a plea
Posted by Erik Huelsmann <eh...@gmail.com>.
> In summary:
>
> 1: Adding keywords is (almost) always a GOOD IDEA ... just need to
> take care in a few cases
> 2: Getting keywords to work in most version control systems is simple
> 3: In SVN it is very hard:
> i: Requires a special setting on each file
This is a very explicit choice. RCS/CVS have damaged many files
because the user didn't specify -kb on the initial import. Many times,
this was discovered too late to repair the damage (ie the original
file was gone by the time it was discovered). Subversion won't change
the content of your files until *explicitly* told to do so.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org