You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Leandro Lucarella <ll...@mecon.gov.ar> on 2002/09/04 16:27:30 UTC
Feature request: keywords ideas.
Hi there. I miss not only $Id$ keywords of CVS (I've seen a patch to make
it available in svn recently) but the $Log$ one too. And I think it would
very nice to have arbitrary keyword expansions based on properties, like
this:
svn ps Manteiner "john foo" file.c
svn ps svn:keywords "Author Manteiner" file.c
So, when I put $Manteiner$ in file.c it wold be expanded to $Manteiner:
john foo$.
This is just an idea, I think I would make keywords much more powerfull
and usefull :)
--
Leandro Lucarella @ MEcon .-----------------------------.
/ Powered by Debian GNU/Linux |
.-----------------------------------------------------------------------------|
| GPG Key: http://bal748.mecon.ar/~luca/public_key.gpg |
| GPG Key Fingerprint: 716E 4896 93B2 640D 917D 96D8 4B16 3177 C864 D90B |
`-----------------------------------------------------------------------------'
Siempre se ha creído que existe algo que se llama destino, pero siempre se ha
creído también que hay otra cosa que se llama albedrío. Lo que califica al
hombre es el equilibrio de esa contradicción.
-- Gilbert Chesterton. (1874-1936) Escritor británico.
Re: Feature request: keywords ideas.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Peter Davis <pe...@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
Re: Feature request: keywords ideas.
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 05 September 2002 09:38, Karl Fogel wrote:
> Well, they can be used for associating metadata with a file, metadata
> that you don't want to appear in the text of the file itself. But
> that's not the case with the keywords you described, because their
> whole purpose is to appear in the text of the file :-).
Then why have keywords at all? The revision, date, author, and url are all
metadata about a file, which anyone can find out with any number of other svn
commands (st, log, ls, etc.).
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.
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 :)
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: keywords ideas.
Posted by Leandro Lucarella <ll...@mecon.gov.ar>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Fogel, el jueves 5 de septiembre a las 11:38 me escribiste:
> Leandro Lucarella <ll...@mecon.gov.ar> writes:
> > I don't know what are arbitrary properties for if you don't find this
> > useful :-P
> > Seriosly, what is the use you find for properties?
>
> Well, they can be used for associating metadata with a file, metadata
> that you don't want to appear in the text of the file itself. But
> that's not the case with the keywords you described, because their
> whole purpose is to appear in the text of the file :-).
That was just an example. Anyway I don't see why the option (just the
option, nobody force you to use it) to put this metadata in the file too
(like Date, Author, etc metadata) won't be useful.
- --
Leandro Lucarella @ MEcon .-----------------------------.
/ Powered by Debian GNU/Linux |
.-----------------------------------------------------------------------------|
| GPG Key: http://bal748.mecon.ar/~luca/public_key.gpg |
| GPG Key Fingerprint: 716E 4896 93B2 640D 917D 96D8 4B16 3177 C864 D90B |
`-----------------------------------------------------------------------------'
Cualquier precio pasado fue mejor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9d5BH7T/vBXlJp7MRAhqBAJ0Zp9O/58FlFtZBcnMLrlCOXLKmAQCeJ1jB
4IjSz+yUQIKr6hXN1u8Iycs=
=hA4+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: keywords ideas.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Leandro Lucarella <ll...@mecon.gov.ar> writes:
> I don't know what are arbitrary properties for if you don't find this
> useful :-P
> Seriosly, what is the use you find for properties?
Well, they can be used for associating metadata with a file, metadata
that you don't want to appear in the text of the file itself. But
that's not the case with the keywords you described, because their
whole purpose is to appear in the text of the file :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: keywords ideas.
Posted by Leandro Lucarella <ll...@mecon.gov.ar>.
Karl Fogel, el jueves 5 de septiembre a las 10:27 me escribiste:
> Leandro Lucarella <ll...@mecon.gov.ar> writes:
> > Hi there. I miss not only $Id$ keywords of CVS (I've seen a patch to make
> > it available in svn recently)
>
> That patch was applied -- Subversion now has the $Id$ keyword.
>
> > but the $Log$ one too. And I think it would
> > very nice to have arbitrary keyword expansions based on properties, like
> > this:
>
> We decided a while back that $Log$ is too rarely used, and too
> unexpected in its expansion behaviors, to be worth implementing. I
> don't have the thread here, but you should be able to find it in the
> dev list archives, and I know Branko ??ibej was one of the posters :-).
>
> > svn ps Manteiner "john foo" file.c
> > svn ps svn:keywords "Author Manteiner" file.c
> >
> > So, when I put $Manteiner$ in file.c it wold be expanded to $Manteiner:
> > john foo$.
> >
> > This is just an idea, I think I would make keywords much more powerfull
> > and usefull :)
>
> Why not just write "Maintainer: John Foo" directly in the file? :-)
It's easier to make svn ps Manteiner "John Foo" file1 file2 ... filen
that enter to n files and edit them by hand.
> In other words, I don't see how this idea really makes keywords any
> more powerful. If you have to maintain the property's value, you
I don't know what are arbitrary properties for if you don't find this
useful :-P
Seriosly, what is the use you find for properties?
> might as well just dispense with the property and maintain a bit of
> text in the file.
Yes, I could not use snv and make backups of my code too, but that's not
the idea :-)
--
Leandro Lucarella @ MEcon .-----------------------------.
/ Powered by Debian GNU/Linux |
.-----------------------------------------------------------------------------|
| GPG Key: http://bal748.mecon.ar/~luca/public_key.gpg |
| GPG Key Fingerprint: 716E 4896 93B2 640D 917D 96D8 4B16 3177 C864 D90B |
`-----------------------------------------------------------------------------'
Un principio no puede ser producido, pues, si lo fuera, dejaría de ser
principio.
-- Platón. (427-347 a.C.) Filósofo griego.
Re: Feature request: keywords ideas.
Posted by Bill Newcomb <nu...@juniper.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Not quite. One of the things i thought of for the keyword format
> string was a %k specifer, which would expand to a keyword.
> Here's an example:
>
> # Something like this in some repo-side conf file:
> [custom keywords]
> keyword NetBSD = "%n %r %d %a"
> keyword BuildStatus = "%r %k(netbsd:build-status)"
>
> Set the svn:keywords property on your file to 'NetBSD
> BuildStatus' and check it in. As different versions of this file
> on different branches are auto-built, the BuildStatus will change
> (if you have your build scripts set the netbsd:build-status
> property).
>
> /*
> $NetBSD: foo.c 270 2002-09-02 02:23:31Z epg $
> $BuildStatus: 270 failed $
> */
>
> or
>
> /*
> $NetBSD: foo.c 261 2002-08-02 02:23:31Z epg $
> $BuildStatus: 261 success $
> */
Changing the property on a file involves a commit, right? So if you
checkout, then build, you'd have to change the netbsd:build-status
property on the file, then check in the change, but at that point the
rev that you are tarballing is different from the one that passed the
build-testing (though hopefully in a trivial way).
I've been thinking of a proposal for per-revision properties that
might work better for this, though it would still need some keyword
substituting changes to solve this problem completely. I was gonna
wait till I had more substance to back it up, but the gist of it is
thus:
The idea would be to have arbitrary properties on revisions (as I
understand it, the log message is currently a property of each
revision), specified in the repo-side config file, and have the values
settable somehow at commit time (I haven't yet thought of a ui for
this that I really like) or changeable later with svnadmin, much like
the log message is now.
F'rinstance, if you set the repo to have revision properties called
'myproj:issue' and 'myproj:reviewer', you could do something like
$ svn commit -m "Fixed the problem" --set-rev-prop "myproj:issue=123" \
--set-rev-prop "myproj:reviewer=fred"
And subsequently someone could determine that your commit was
associated with Issue 123 and reviewed by fred without having to grep
through logs.
Or, to take the case of the build-status above, if you set the
revision property 'netbsd:build-status' for the repository, you could
go back later and
$ svnadmin revpropset myrepo 261 'netbsd:build-status' 'success'
(or something; I know that really starts to get verbose...)
Unfortunately I haven't had the spare time to grovel through the
sources enough to actually try to implement this idea. If anyone else
thinks this is nifty/easy-to-implement enough to work on it, go nuts.
Cheers,
-B.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: keywords ideas.
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Why not just write "Maintainer: John Foo" directly in the file? :-)
>
> In other words, I don't see how this idea really makes keywords any
> more powerful. If you have to maintain the property's value, you
> might as well just dispense with the property and maintain a bit of
> text in the file.
Not quite. One of the things i thought of for the keyword format
string was a %k specifer, which would expand to a keyword.
Here's an example:
# Something like this in some repo-side conf file:
[custom keywords]
keyword NetBSD = "%n %r %d %a"
keyword BuildStatus = "%r %k(netbsd:build-status)"
Set the svn:keywords property on your file to 'NetBSD
BuildStatus' and check it in. As different versions of this file
on different branches are auto-built, the BuildStatus will change
(if you have your build scripts set the netbsd:build-status
property).
/*
$NetBSD: foo.c 270 2002-09-02 02:23:31Z epg $
$BuildStatus: 270 failed $
*/
or
/*
$NetBSD: foo.c 261 2002-08-02 02:23:31Z epg $
$BuildStatus: 261 success $
*/
Now i can tell by looking in the nightly tar file whether it
successfully built or not. I can think of plenty other uses for
such a feature, i'm sure.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: keywords ideas.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Leandro Lucarella <ll...@mecon.gov.ar> writes:
> Hi there. I miss not only $Id$ keywords of CVS (I've seen a patch to make
> it available in svn recently)
That patch was applied -- Subversion now has the $Id$ keyword.
> but the $Log$ one too. And I think it would
> very nice to have arbitrary keyword expansions based on properties, like
> this:
We decided a while back that $Log$ is too rarely used, and too
unexpected in its expansion behaviors, to be worth implementing. I
don't have the thread here, but you should be able to find it in the
dev list archives, and I know Branko Čibej was one of the posters :-).
> svn ps Manteiner "john foo" file.c
> svn ps svn:keywords "Author Manteiner" file.c
>
> So, when I put $Manteiner$ in file.c it wold be expanded to $Manteiner:
> john foo$.
>
> This is just an idea, I think I would make keywords much more powerfull
> and usefull :)
Why not just write "Maintainer: John Foo" directly in the file? :-)
In other words, I don't see how this idea really makes keywords any
more powerful. If you have to maintain the property's value, you
might as well just dispense with the property and maintain a bit of
text in the file.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org