You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/12/13 10:16:38 UTC
keywords
The keywords seem awfully lengthy. I'd like to suggest some alternatives:
LastChangedRevision -> Revision
LastChangedDate -> Date
LastChangedBy -> Author
HeadURL (no change)
The "LastChanged" seems self-evident and (therefore) redundant.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
This sounds good, but for post-1.0.
-K
"Jonathan M. Manning" <jm...@alisa-jon.net> writes:
> Hi, with all the traffic lately, I wanted to put a few ideas together
> from this thread before they got lost.
>
> Alias-based solution to:
> Keyword Internationalization & Short Keywords & Long Keywords & Custom
> Aliases.
>
> Summary:
> For svn keyword translation, implement *just* the Long Keywords.
> Provide an alias mechanism for defining custom keywords.
>
> All the rest (internationalization, short keywords, id, etc) all
> become just aliases.
>
> So you would define short keywords, non-english keywords, custom
> aliases, etc in a keyword_alias file/properties on a per-project basis.
>
>
> More details:
>
> There should be a basic default set of aliases, which includes the
> short keywords, id, etc.
> id: FileName Date Author Revision
> Revision: LastChangedRevision
> Date: LastChangedDate
> Author: LastChangedBy
>
> Then add what you need for your project:
>
> (Whatever you need for the people working on your project to
> understand the meaning of these fields. Please forgive the rough
> translations.)
> Autor: Author
> auteur: Author
> Datums: Date
> fecha: Date
> Neuausgabe: Revision
>
> Project specific:
> FreeBSD: FileName FreeBSDVersion Date Author Revision
> NetBSD: ... NetBSDVersion ...
> (though never both defined in the same project...) It should ignore
> unknown keywords.
>
>
> This is far from all the details needed, but it's the basic format of
> a keywords system that handles all the exception cases mentioned so
> far... reduced to a single alias-based system.
>
> Thoughts?
>
> ~Jonathan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by "Jonathan M. Manning" <jm...@alisa-jon.net>.
Hi, with all the traffic lately, I wanted to put a few ideas together from
this thread before they got lost.
Alias-based solution to:
Keyword Internationalization & Short Keywords & Long Keywords & Custom
Aliases.
Summary:
For svn keyword translation, implement *just* the Long Keywords.
Provide an alias mechanism for defining custom keywords.
All the rest (internationalization, short keywords, id, etc) all become
just aliases.
So you would define short keywords, non-english keywords, custom aliases,
etc in a keyword_alias file/properties on a per-project basis.
More details:
There should be a basic default set of aliases, which includes the short
keywords, id, etc.
id: FileName Date Author Revision
Revision: LastChangedRevision
Date: LastChangedDate
Author: LastChangedBy
Then add what you need for your project:
(Whatever you need for the people working on your project to understand the
meaning of these fields. Please forgive the rough translations.)
Autor: Author
auteur: Author
Datums: Date
fecha: Date
Neuausgabe: Revision
Project specific:
FreeBSD: FileName FreeBSDVersion Date Author Revision
NetBSD: ... NetBSDVersion ...
(though never both defined in the same project...) It should ignore unknown
keywords.
This is far from all the details needed, but it's the basic format of a
keywords system that handles all the exception cases mentioned so far...
reduced to a single alias-based system.
Thoughts?
~Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Alexander Mueller <al...@littleblue.de>.
So what about internationalization?
Id will understand almost everybody.
LastChangedDate sounds like English, probably it is English?
I know, this is kind of heavy. But its not all just Egnlish speaking. And I know a lot of customers that are willing to accept "Id", but never "LastChangedDate".
Ben Collins-Sussman schrieb:
> Greg Stein <gs...@lyra.org> writes:
>
> > The keywords seem awfully lengthy. I'd like to suggest some alternatives:
> >
> > LastChangedRevision -> Revision
> > LastChangedDate -> Date
> > LastChangedBy -> Author
>
> We had the same debate in Chicago. I agree that they're annoyingly
> long, BUT... remember that expanded keywords show up in documents that
> are read by people who know nothing about version control. If they
> see a "$Date: ...$", or "$Author: ...$" in a document, they may think
> that the document was created on a single date or written by a single
> author. The "LastChanged" prefix indicates that the document has
> evolved, via many authors.
>
> Is this silly?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> The keywords seem awfully lengthy. I'd like to suggest some alternatives:
>
> LastChangedRevision -> Revision
> LastChangedDate -> Date
> LastChangedBy -> Author
We had the same debate in Chicago. I agree that they're annoyingly
long, BUT... remember that expanded keywords show up in documents that
are read by people who know nothing about version control. If they
see a "$Date: ...$", or "$Author: ...$" in a document, they may think
that the document was created on a single date or written by a single
author. The "LastChanged" prefix indicates that the document has
evolved, via many authors.
Is this silly?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> Seems like overkill, though I can't think of any particular cases where
> it would cause a problem.
>
> How is the client supposed to know what the last changed revision is, by
> the way?
Very perceptive question. :-)
It's going to have to come down in the update stream; we can intercept
special editor change_foo_prop() calls to set it in the entries file.
For commits, the rev bumping function will do it of course.
I think it was Ben or Mike who thought up this solution.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2001-12-13 at 13:07, Karl Fogel wrote:
> We should support both ways. If your audience needs long keywords
> whose meaning is immediately clear, use those; if your audience is
> other Subversion users, use the shorter ones.
Seems like overkill, though I can't think of any particular cases where
it would cause a problem.
How is the client supposed to know what the last changed revision is, by
the way?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> > LastChangedRevision -> Revision
> > LastChangedDate -> Date
> > LastChangedBy -> Author
> >
> > HeadURL (no change)
> >
> >
> > The "LastChanged" seems self-evident and (therefore) redundant.
>
> I thought it was necessary, and argued hard with Mike and Ben for
> including the "LastChanged" prefix. But now that I actually see it in
> examples, I have to agree with you three -- it's annoying.
>
> +1 on the shorter versions.
Duh. I forgot the most obvious answer:
We should support both ways. If your audience needs long keywords
whose meaning is immediately clear, use those; if your audience is
other Subversion users, use the shorter ones.
Hmmm. Is it bad to have a few different forms of each keyword? Will
that just be more confusing?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keywords
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> The keywords seem awfully lengthy. I'd like to suggest some alternatives:
>
> LastChangedRevision -> Revision
> LastChangedDate -> Date
> LastChangedBy -> Author
>
> HeadURL (no change)
>
>
> The "LastChanged" seems self-evident and (therefore) redundant.
I thought it was necessary, and argued hard with Mike and Ben for
including the "LastChanged" prefix. But now that I actually see it in
examples, I have to agree with you three -- it's annoying.
+1 on the shorter versions.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org