Peter Davis <peter@pdavis.cx> writes:
> I think the issue, and the reason why including not only the preset
> keywords but any arbitrary metadata in a file is good, is that once
> a file is exported from its working-copy environment (svn export, or
> just as a result of a build process), all the svn metadata that
> isn't included in the text of a file is lost. If I want to get
> metadata other than the five preset keywords, I'm SOL once the
> source is exported.
Huh? But if one just inserted text directly, instead of going through
these new keywords, the data *would* be present in the exported file,
because it would be part of the text of the file.
The point is that if the data is static, and its destination is the
file text anyway, then it's not "meta"data. It's just data, so
version it like, you know, data :-).
> So, why have keywords if they can't be redefined? I guess the only
> difference between the predefined keywords and arbitrary ones is
> that they are automatically updated for each commit, whereas
> arbitrary ones would require a separate propset command. As Leandro
> said, "svn ps Maintainer 'John Doe' file1 file2 file3..." still has
> advantages over editing each file by hand. I suppose one could
> write a perl script to do that, but I hope you see the point :)
The current svn keywords (date, author, lastrev, etc) are useful
because they are data that you can't easily get into a working file by
other means. If you tried to hand-edit the lastrev, it would be out
of date as soon as you commit. Same with date. If you want to set
the URL, you'd need to parse the output of 'svn info' or something.
So these keywords are giving us something we can't conveniently get
any other way.
But replacing bits of text in a file with *static*, non-computed
property values does not give us something we can't get another way.
Instead, it gives us something we can already get by simply editing
the file and committing.
(The reason Eric Gillespie's proposal is different is that, again, the
values are dynamic, not static strings. That makes all the
difference.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 5 21:49:17 2002