You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexis Huxley <ah...@gmx.net> on 2002/05/02 13:14:10 UTC
'stamping' a la RCS '$Header$'?
Hi
Is this possible? Is there some '$header$' or '#(@)'-like string I can
put in my sources which will be substituted at checkout time for
revision number, date, last-modified by etc?
I guess since SVN can handle binary data that it isn't quite that
simple? :-)
Thanks!
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository! and Re: 'stamping' a la RCS '$Header$'?
Posted by Alexis Huxley <ah...@gmx.net>.
Ben wrote:
> > in SVN itself: what does "version 1.0" actually mean? I mean it
> > must really map to repository revision, right?
>
> Sure, although we'll probably create a 1.0 branch, and keep /trunk
> moving forward. So it's better to say that Subversion 1.0 corresponds
> to a revision and a *path*, not just a revision.
Karl wrote:
> $Id$ ===> "$Id http://some.url/blah/blah/andsoforth @ 1661"
Yes, those two tie up very nicely: a release id maps to a [sub]directory
of the repository together with one of the (possibly multiple) repository
revisions in which the files were in a particular state; the first
revision would seem the logical one, because then ...
Russ wrote:
> > and not include Author and Date?
... *that* would make more sense. And definitely - for example in
versioned web pages, - it is nice to see that information in the small
print.
> Please include the date; that's the most useful information in all of $Id$
> for someone looking at the file outside of a version control environment.
>
> I don't see any need for the URL either. The RCS version doesn't include
> it the full path, just the file name.
Yes, it does. It depends whether you use '$Header$' or '$Id$'. I can't
remember which way round it is, but one gives you the full path and the
other one doesn't.
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Russ Allbery <rr...@stanford.edu>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Unless someone has a concrete description of how this would work,
> including where the mappings get defined, I'm +1 on just defining
> $Id$ ===> "$Id Rev <xxx>, jrandom, <date> $"
> I think it would be a mistake to include URL in $Id$, though. URLs
> tend to be long, and so most people would want to put them on a line
> right below the $Id$.
> Or maybe $Id$ should be
> $Id$ ===> "$Id http://some.url/blah/blah/andsoforth @ 1661"
> and not include Author and Date?
Please include the date; that's the most useful information in all of $Id$
for someone looking at the file outside of a version control environment.
I don't see any need for the URL either. The RCS version doesn't include
it the full path, just the file name.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/03 15:13 +0200, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Right. Hm. On the one hand, you'd want the format strings to be global to
>the repository. On the other hand, you want them versioned. The notion of
>"repository properties" comes to mind. They'd be versioned like node
>properties, but apply to the whole repository, and accessible through any
>node. Say in the "svn:repo:" namespace.
This goes back to multiple projects. You may want to have a format string
defined one way in one project an another way in another project (imagine,
for example that you do work for multiple clients, each with slight but
strict differences in how $Id$ should be formatted). You may want some
format strings defined for one project and not for another.
How about building a list of defined keywords and their formats by defining
them at the directory level and working your way up to the root looking for
definitions, with the lowest-level definition taking precedence? For example:
/stuff defines
$Id$ = "<author> <date yyyy.mm.dd>"
/stuff/client1 defines
$Id$ = "<author> <version> <date mm/dd/yy>"
$Copy$ = "(c)1998-<date yyyy> Client One Inc."
/stuff/client2 defines
$Id$ = "<author> <rootfile> <version>:<rev>"
$Copy$ = "(c)2002 Client Two Corp."
$Credits$ = "Brought to you by the cool guys at Cool Guys Inc."
So in this structure $Credits$ is only defined for files defined under the
client2 directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>cmpilato@collab.net writes:
>
>>Yeah, see the problem here is that you set your format string property
>>on trunk. But what if I only check out some sub-tree under trunk?
>>This scenario will inevitably lead to setting your format string
>>property on every directory (since you don't know what portion of the
>>tree folks will check out). But if you're going to be setting the
>>same property so many times, why not set it instead only the files
>>that want to expand it?
>>
>
>But maybe the format strings could be configured in some text file in
>the repository (I mean "in the repository" in the sense that the hook
>scripts are in the repository), and the client would fetch that file.
>That way, the custom keywords would be global to that repository,
>which matches the administrative boundaries that exist in real life.
>
Right. Hm. On the one hand, you'd want the format strings to be global
to the repository. On the other hand, you want them versioned. The
notion of "repository properties" comes to mind. They'd be versioned
like node properties, but apply to the whole repository, and accessible
through any node. Say in the "svn:repo:" namespace.
It's a pity they'd play havoc with the way we handle properties in the
WC ATM ...
Just thinking out loud.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Can we please get the basename(3) of the URL in there? Not
> http://foo/trunk/sysdeps/linux.in, but linux.in. The name of a
> file you are trying to ident(1) is not always the same name it has
> in the repository.
Sure, I don't see why that would be a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> This seems like a lot of work. On the other hand, a lot of people
Indeed it does. I think properties are better suited for this.
> I think this would be our best course:
I agree, with one request:
> Implement "$Id$" for 1.0. It will be rev, author, and date.
Can we please get the basename(3) of the URL in there? Not
http://foo/trunk/sysdeps/linux.in, but linux.in. The name of a
file you are trying to ident(1) is not always the same name it has
in the repository.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
cmpilato@collab.net writes:
> Yeah, see the problem here is that you set your format string property
> on trunk. But what if I only check out some sub-tree under trunk?
> This scenario will inevitably lead to setting your format string
> property on every directory (since you don't know what portion of the
> tree folks will check out). But if you're going to be setting the
> same property so many times, why not set it instead only the files
> that want to expand it?
But maybe the format strings could be configured in some text file in
the repository (I mean "in the repository" in the sense that the hook
scripts are in the repository), and the client would fetch that file.
That way, the custom keywords would be global to that repository,
which matches the administrative boundaries that exist in real life.
The client and server would have to checksum and/or datestamp the
file, to get it when it changes. Or just refetch it every time.
This seems like a lot of work. On the other hand, a lot of people
were asking for support for customizable keyword expansion. On the
*other* tentacle, it's a slippery slope into becoming a generic text
transformation tool as well as a revision control system.
I think this would be our best course:
Implement "$Id$" for 1.0. It will be rev, author, and date.
If anyone submits a patch for customizable keywords, one that looks
like it'll work robustly, we should use it. If not, we can still do
it (perhaps using the scheme described above), but post-1.0.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
cmpilato@collab.net writes:
> It's the "or doesn't" case that scares me...but then, now that I think
It shouldn't. When i originally proposed this, i said that if it
can't find the definition it doesn't expand it. This is no different
that putting $Blah$ into a file in the current svn :).
> Alright, I'm convinced. There's some merit to your method.
Heh, OK.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by cm...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> cmpilato@collab.net writes:
>
> > admittedly that your idea may not be a good one, I was just trying to
> > help you remove your uncertainly of its Badness. ;-)
>
> But you didn't remove the uncertainty:
>
> > > Yeah, see the problem here is that you set your format string property
> > > on trunk. But what if I only check out some sub-tree under trunk?
>
> > Like i said, it climbs the directory tree until it finds it (or
> > doesn't).
>
> In any case, defining the custom keyword on all 1000 files that
> are going to have it in my repo is not an option. What happens
> when the keyword changes?
It's the "or doesn't" case that scares me...but then, now that I think
about it, it doesn't really scare me that much. I mean, if it doesn't
find the keyword property, the worst thing that happens is that that
keyword won't get expanded. Even if the user commits that file, it
shouldn't cause any problems because again, the keyword won't be
treated as special.
Alright, I'm convinced. There's some merit to your method.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
cmpilato@collab.net writes:
> admittedly that your idea may not be a good one, I was just trying to
> help you remove your uncertainly of its Badness. ;-)
But you didn't remove the uncertainty:
> > Yeah, see the problem here is that you set your format string property
> > on trunk. But what if I only check out some sub-tree under trunk?
> Like i said, it climbs the directory tree until it finds it (or
> doesn't).
In any case, defining the custom keyword on all 1000 files that
are going to have it in my repo is not an option. What happens
when the keyword changes?
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by cm...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Yes. We're trying to reach a good solution, and hacking on your
> > proposal is the most direct route.
> >
> > The originator's opinion of his proposal is no more important than
> > anyone else's :-).
>
> Fair enough :). I'm just trying to make sure using properties to
> solve this problem isn't discounted purely on the basis of a
> (possibly faulty) proposed method.
Nah, I think properties are a fine way to do this (if we do it at
all). You just provided a springboard for discussion, and while you
admittedly that your idea may not be a good one, I was just trying to
help you remove your uncertainly of its Badness. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Yes. We're trying to reach a good solution, and hacking on your
> proposal is the most direct route.
>
> The originator's opinion of his proposal is no more important than
> anyone else's :-).
Fair enough :). I'm just trying to make sure using properties to
solve this problem isn't discounted purely on the basis of a
(possibly faulty) proposed method.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> First let me say that you and Karl are nit-picking the specifics
> of the proposal that i specifically said might not be a good idea :).
Yes. We're trying to reach a good solution, and hacking on your
proposal is the most direct route.
The originator's opinion of his proposal is no more important than
anyone else's :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
First let me say that you and Karl are nit-picking the specifics
of the proposal that i specifically said might not be a good idea :).
cmpilato@collab.net writes:
> Yeah, see the problem here is that you set your format string property
> on trunk. But what if I only check out some sub-tree under trunk?
Like i said, it climbs the directory tree until it finds it (or
doesn't).
> same property so many times, why not set it instead only the files
> that want to expand it?
This might be a better idea. I already said i wasn't sure about
the specifics.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by cm...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Yeah. We had some proposals for a super-sophisticated keyword "alias"
> > mechanism, where people could define custom combination keywords. But
> > it was never clear where the mapping would be stored (or maybe I'm
> > just not remembering the proposals well enough?)
>
> I proposed a format string solution, but didn't know enough about
> svn to comment on implementation details. Now i know a bit more,
> and have an idea: put the information in directory properties.
> For example, if svn:keywords lists an unknown keyword 'foo' check
> for the presence of a property custom-keyword:foo on the current
> directory and keep climbing up the directory tree until you find
> one. If you don't find one, don't expand it, if you do, expand it
> to the string specified there, replacing format specifiers.
>
> So i could set svn:keywords to 'Progeny' on all the files we modify
> and set custom-keyword:Progeny to '%f %r %d %a' on /trunk. %f is
> base filename (which svn doesn't currently support but should), %r
> is revision, %d is date, and %a is author.
Yeah, see the problem here is that you set your format string property
on trunk. But what if I only check out some sub-tree under trunk?
This scenario will inevitably lead to setting your format string
property on every directory (since you don't know what portion of the
tree folks will check out). But if you're going to be setting the
same property so many times, why not set it instead only the files
that want to expand it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Yeah. We had some proposals for a super-sophisticated keyword "alias"
> mechanism, where people could define custom combination keywords. But
> it was never clear where the mapping would be stored (or maybe I'm
> just not remembering the proposals well enough?)
I proposed a format string solution, but didn't know enough about
svn to comment on implementation details. Now i know a bit more,
and have an idea: put the information in directory properties.
For example, if svn:keywords lists an unknown keyword 'foo' check
for the presence of a property custom-keyword:foo on the current
directory and keep climbing up the directory tree until you find
one. If you don't find one, don't expand it, if you do, expand it
to the string specified there, replacing format specifiers.
So i could set svn:keywords to 'Progeny' on all the files we modify
and set custom-keyword:Progeny to '%f %r %d %a' on /trunk. %f is
base filename (which svn doesn't currently support but should), %r
is revision, %d is date, and %a is author.
That's just one way to do it with properties. I'm not sure it's
the best way or even if it's possible (i know little about the
implementation of properties), but i do think properties would be
a good way to accomplish it.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nathan Fiedler <nf...@bluemarsh.com> writes:
> By the way, the keywords are: Author, Date, Rev, and URL. Simply set the
> property described below to "Author Date Rev URL". Then put $Author: $
> or whatever in your files. Be sure to have the space after the colon
> though.
Actually, "$Author$" should work as an initial value.
> While these keywords address the important bits of information, I would
> like to add my vote for an all-inclusive keyword, such as Id or Header.
Yeah. We had some proposals for a super-sophisticated keyword "alias"
mechanism, where people could define custom combination keywords. But
it was never clear where the mapping would be stored (or maybe I'm
just not remembering the proposals well enough?)
Unless someone has a concrete description of how this would work,
including where the mappings get defined, I'm +1 on just defining
$Id$ ===> "$Id Rev <xxx>, jrandom, <date> $"
I think it would be a mistake to include URL in $Id$, though. URLs
tend to be long, and so most people would want to put them on a line
right below the $Id$.
Or maybe $Id$ should be
$Id$ ===> "$Id http://some.url/blah/blah/andsoforth @ 1661"
and not include Author and Date?
Either way, we should avoid all four on the same line. It usually
won't fit in 80 columns.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Nathan Fiedler <nf...@bluemarsh.com>.
Who needs docs when there's the source code? ;)
By the way, the keywords are: Author, Date, Rev, and URL. Simply set the
property described below to "Author Date Rev URL". Then put $Author: $
or whatever in your files. Be sure to have the space after the colon
though.
While these keywords address the important bits of information, I would
like to add my vote for an all-inclusive keyword, such as Id or Header.
nathan
On Thu, 2002-05-02 at 06:26, Ben Collins-Sussman wrote:
> Alexis Huxley <ah...@gmx.net> writes:
>
> > Is this possible? Is there some '$header$' or '#(@)'-like string I
can
> > put in my sources which will be substituted at checkout time for
> > revision number, date, last-modified by etc?
>
> Read include/svn_types.h, and grep down to /*** Keyword Substitution
***/
> section. We support 4 keywords -- you just need to activate them by
> setting the svn:keywords property on a file.
>
> Man, we really need docs. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Alexis Huxley <ah...@gmx.net> writes:
>
> > Is this possible? Is there some '$header$' or '#(@)'-like string I can
> > put in my sources which will be substituted at checkout time for
> > revision number, date, last-modified by etc?
>
> Read include/svn_types.h, and grep down to /*** Keyword Substitution ***/
> section. We support 4 keywords -- you just need to activate them by
> setting the svn:keywords property on a file.
For an example, look at how we're doing a date replacement on our
README file at the top of our source tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexis Huxley <ah...@gmx.net> writes:
> Is this possible? Is there some '$header$' or '#(@)'-like string I can
> put in my sources which will be substituted at checkout time for
> revision number, date, last-modified by etc?
Read include/svn_types.h, and grep down to /*** Keyword Substitution ***/
section. We support 4 keywords -- you just need to activate them by
setting the svn:keywords property on a file.
Man, we really need docs. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'stamping' a la RCS '$Header$'?
Posted by cm...@collab.net.
Alexis Huxley <ah...@gmx.net> writes:
> Is this possible? Is there some '$header$' or '#(@)'-like string I can
> put in my sources which will be substituted at checkout time for
> revision number, date, last-modified by etc?
>
> I guess since SVN can handle binary data that it isn't quite that
> simple? :-)
There's an issue filed about just such a feature requests...can't
recall the issue number, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org