Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
all
Description
Currently, Subversion provides a limited set of keywords: LastChangedRevision (Rev), LastChangedDate (Date), LastChangedBy (Author), HeadURL (URL), and Id. These keywords are fine for many, if not most, purposes. But many projects have more complex needs. The BSD projects are good examples. Rather than using the Id CVS keyword, they have patched CVS to allow a keyword named after the project (e.g. $FreeBSD$ for FreeBSD). This keyword looks like Id, but has multiple advantages. When importing files from another repository, you can use the -ko option to turn off keyword expansion. Unfortunately, that's an either/or. What you really want is to expand your own keyword but not the other project's. Project-named keywords solve this problem. It is easy to tell what revision of the file each project has. For example, looking at <http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/libexec/atrun/atrun.8?rev=1.10&content-type=text/x-cvsweb-markup> we see: .\" $NetBSD: atrun.8,v 1.10 2000/11/07 06:43:25 lukem Exp $ .\" $OpenBSD: atrun.8,v 1.4 1998/05/22 22:16:29 deraadt Exp $ .\" $FreeBSD: atrun.man,v 1.3 1997/02/22 14:20:55 peter Exp $ CVS has no support for this feature. Each project that uses the feature has had to patch in the support themselves. With Subversion, we can get it right and implement a generic solution. To do this, i propose the use of printf(3)-style format strings. Subversion will not support any keywords "natively". Instead, it will come with a default set of keyword definitions in the default repo configuration file. The default set of keyword definitions is: keyword Rev = "%r" keyword Date = "%d" keyword Author = "%a" keyword URL = "%u" keyword URLBaseName = "%b" # (desperately needs a better name) keyword Id = "%b %r %d %a" The format characters are defined as follows: a author of this revision b last component of the URL of this file; think basename(3) d date of this revision p property value r number of this revision u URL of this file The 'p' character is special. Its usage resembles a C or Perl function call that takes one argument, the name of a property. For example, given this keyword definition: keyword MimeType = "%p(svn:mime-type)" and a file with the properties svn:mime-type 'text/html' and svn:keywords 'MimeType', the keywords expands like this: $MimeType: text/html $ Not the most useful thing in the world. For a better example, imagine an auto-builder which checks out various branches of a project and sets a property on some file indicating the build status. Then, given this keyword definition: keyword BuildStatus = "$u %p(foo:build-status)" we might see this: $BuildStatus: http://example.com/svn/branch1/STATUS success $ or: $BuildStatus: http://example.com/svn/branch2/STATUS failure $ Since this information is stored in the repository, a mechanism for the client to receive configuration data from the repository is necessary. Describing such a mechanism is beyond the scope of this proposal. Note that all the examples given here are just that: examples. It doesn't particularly matter what syntax is used, or how far off i am from svn config file syntax. Some messages on the dev list that may be of interest: Subject: Customizable Keywords http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=8735 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=8757 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=8842 Subject: 'stamping' a la RCS '$Header$'? http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14104 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14105 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14106 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14129
Original issue reported by epg