You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Duncan Murdoch <mu...@stats.uwo.ca> on 2004/10/27 13:05:19 UTC
Global revision keyword
Last year there was a discussion on this list about the problems of
implementing an svn:keywords subsitution keyword which puts in place
the global revision of a source tree. The general impression I got
from reading it was that this was too much of a special case need to
justify putting it in.
First of all, has this changed? I don't see it in the book, but is it
there now?
If not, has anyone written a hook script to have the same effect? For
example, I'd like a script that did the following:
If there's a commit to the trunk, then before acting on it, the script
would write something (the new revision number, if that's available,
or maybe just a timestamp) to a version file, and add that file to the
commit. If the commit is to a branch, it would write to the file in
that branch.
To explain why this would be desirable, some background:
I'm working on the R project, an open source statistics package that
runs on lots of different platforms. We distribute it in several
different forms: tarballs of source built from a repository checkout,
public access to the repository using https://..., binary builds from
checkouts, binary builds from tarballs, and maybe some others.
Only the people doing builds from a checkout could run svnversion as
part of the build process to get a version stamp into it, so we have a
daily script that writes and commits a date-stamp file. This works,
but it's inaccurate (a build may be several commits away from the time
the date-stamp file was built) and it fills up the log with boring
"(auto)" commits of the date stamp to the trunk and patched branches:
<http://developer.r-project.org/R.svnlog.2004>.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
On Wed, 27 Oct 2004 15:38:36 +0200, SteveKing
<st...@wagner-group.ch> wrote :
>Duncan Murdoch wrote:
>> Last year there was a discussion on this list about the problems of
>> implementing an svn:keywords subsitution keyword which puts in place
>> the global revision of a source tree. The general impression I got
>> from reading it was that this was too much of a special case need to
>> justify putting it in.
>
>You mean this:
>http://subversion.tigris.org/project_faq.html#version-value-in-source
>?
Yes, that's what I'd like to happen, but the instructions on that page
don't quite work for us. Some people do builds from source tarballs
or from svn export copies. We could use svnversion to put something
into the tarball and tell people using that not to use svnversion; we
could tell the people using svn export to use svnversion in their
builds, so there are definitely workarounds. We're just looking for
the simplest one.
The FAQ you pointed to says this:
>Subversion increments the revision number of the repository as a whole, so it can't expand any keyword to be that number - it would have to search and possibly modify every file in your working copy on every update and commit.
>
That's a problem with one implementation, but that's not the only
implementation. Another would be to store in some global location
(wherever the revision number is stored) a list of files containing
this keyword. Whenever the revision number is updated, those files
would be marked as changed too.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Dominic Anello <da...@danky.com>.
On 2004-10-27 10:28:46 -0500, Ben Collins-Sussman wrote:
>
> On Oct 27, 2004, at 10:26 AM, Dominic Anello wrote:
> >
> >If you have the build number in hand, you can do the following:
> >$ svn log -r1000 -q http://lynx/ec-svn | egrep '^r' | cut -d '|' -f 3
> > 2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
> >
> >If you are building from a working copy you can parse it out of svn
> >info:
> >$ svn info . | egrep '^Last Changed Date:'
> >Last Changed Date: 2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
> >
> >
>
> Or, if you're on windows and don't have greppy tools, just run
>
> $ svn propget svn:date --revprop -r1000 URL
>
> The revision datestamp is a 'property' ofa revision. Much, much
> simpler.
What he said - definately much easier, and you get a nice ISO date.
Thanks Ben!
Re: Global revision keyword
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 27, 2004, at 10:26 AM, Dominic Anello wrote:
>
> If you have the build number in hand, you can do the following:
> $ svn log -r1000 -q http://lynx/ec-svn | egrep '^r' | cut -d '|' -f 3
> 2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
>
> If you are building from a working copy you can parse it out of svn
> info:
> $ svn info . | egrep '^Last Changed Date:'
> Last Changed Date: 2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
>
>
Or, if you're on windows and don't have greppy tools, just run
$ svn propget svn:date --revprop -r1000 URL
The revision datestamp is a 'property' ofa revision. Much, much
simpler.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Dominic Anello <da...@danky.com>.
On 2004-10-27 10:58:44 -0400, Duncan Murdoch wrote:
> After the suggestions here, we're looking at having the people
> building the source tarballs and the binary builds include the version
> information.
>
> One small question: is there an easy way to convert a version number
> into the time of the corresponding commit?
>
> i.e. if I'm doing a build based on revision 1000, I'd like the
> timestamp in the build to give the time of the commit of that
> revision, rather than the time of the build (since there may have been
> more revisions, the clock on the build machine might not agree with
> the repository, etc.)?
>
> I just need a human readable string of some sort.
>
> Duncan Murdoch
If you have the build number in hand, you can do the following:
$ svn log -r1000 -q http://lynx/ec-svn | egrep '^r' | cut -d '|' -f 3
2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
If you are building from a working copy you can parse it out of svn
info:
$ svn info . | egrep '^Last Changed Date:'
Last Changed Date: 2004-04-07 15:34:39 -0400 (Wed, 07 Apr 2004)
-Dominic
Re: Global revision keyword
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
After the suggestions here, we're looking at having the people
building the source tarballs and the binary builds include the version
information.
One small question: is there an easy way to convert a version number
into the time of the corresponding commit?
i.e. if I'm doing a build based on revision 1000, I'd like the
timestamp in the build to give the time of the commit of that
revision, rather than the time of the build (since there may have been
more revisions, the clock on the build machine might not agree with
the repository, etc.)?
I just need a human readable string of some sort.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by SteveKing <st...@wagner-group.ch>.
Duncan Murdoch wrote:
> Last year there was a discussion on this list about the problems of
> implementing an svn:keywords subsitution keyword which puts in place
> the global revision of a source tree. The general impression I got
> from reading it was that this was too much of a special case need to
> justify putting it in.
You mean this:
http://subversion.tigris.org/project_faq.html#version-value-in-source
?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
On Wed, 27 Oct 2004 10:02:23 -0400, Mark Phippard
<Ma...@softlanding.com> wrote :
>But why do developers need or care about this information anyway? I
>thought the issue was that you have a user-base that are pulling from your
>repository or tarballs, and it is with those people that you need this
>information? Developers could just use svnversion as part of a
>build/tarball process.
Lots of our users build their own copies, they don't use the binary
builds that we produce (because R runs on lots of different platforms,
but we have a limited number of builds). When they find a bug in a
snapshot, we want them to be able to tell us which snapshot it was in.
>If you are on Windows, there is also a nice program named SubWCRev.exe
>available from the TortoiseSVN project. This is similar to svnversion,
>except it will do keyword substitition in a file for you.
Thanks for the pointer. I may use that.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Mark Phippard <Ma...@softlanding.com>.
Duncan Murdoch <mu...@stats.uwo.ca> wrote on 10/27/2004 09:49:44 AM:
> We could standardize on a daily tag, and always build the snapshots
> from the last of those: but that would slow the release of bug fixes
> by a few hours, it would load up our log file with all those entries
> where the tag was created, and it would be inconvenient: now I do
>
> svn update
> hack, build, test
> svn commit
> upload
>
> and if we followed this scheme, it would be
>
> svn update
> hack, build, test
> svn commit
> svn switch <tag>
> build, test
> upload
>
> If I fix a bug and commit it, I'd like to do a build from my
> up-to-date source, rather than switching to a tag release and
> rebuilding from that.
>
But why do developers need or care about this information anyway? I
thought the issue was that you have a user-base that are pulling from your
repository or tarballs, and it is with those people that you need this
information? Developers could just use svnversion as part of a
build/tarball process.
If you are on Windows, there is also a nice program named SubWCRev.exe
available from the TortoiseSVN project. This is similar to svnversion,
except it will do keyword substitition in a file for you.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On Wed, 27 Oct 2004 09:20:53 -0400, Mark Phippard
<Ma...@softlanding.com> wrote :
> I think what you would
>want to do is the pretty much the same thing, except do it on the client.
>Create a "svn-commit" script that your users use instead of svn ci. The
>script would do something to update a file, or a property on that file and
>then run svn ci. That would cause that file to be included in the commit,
>and would allow you to then use the LastChangedRevision keyword in that
>file.
Okay, this sounds like a possibility. I think everyone with commit
privileges is running a system that could run such a script.
>The one thing I have not seen, is why it is so necessary to have this
>information in a file to begin with? Why can't you just use a more normal
>release process and use Tags for your releases?
We do that for normal releases; this is for daily snapshots. Those
are produced by a number of different people, operating on different
schedules. For example, I produce binary builds of the Windows
versions of the trunk and patch releases several times per week.
There are also daily tarballs of the source produced for people doing
their own builds, and there may be binary builds for other platforms
too, I'm not sure. Each of these is produced at a different time.
We could standardize on a daily tag, and always build the snapshots
from the last of those: but that would slow the release of bug fixes
by a few hours, it would load up our log file with all those entries
where the tag was created, and it would be inconvenient: now I do
svn update
hack, build, test
svn commit
upload
and if we followed this scheme, it would be
svn update
hack, build, test
svn commit
svn switch <tag>
build, test
upload
If I fix a bug and commit it, I'd like to do a build from my
up-to-date source, rather than switching to a tag release and
rebuilding from that.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Global revision keyword
Posted by Mark Phippard <Ma...@softlanding.com>.
Duncan Murdoch <mu...@stats.uwo.ca> wrote on 10/27/2004 09:05:19 AM:
> Last year there was a discussion on this list about the problems of
> implementing an svn:keywords subsitution keyword which puts in place
> the global revision of a source tree. The general impression I got
> from reading it was that this was too much of a special case need to
> justify putting it in.
>
> First of all, has this changed? I don't see it in the book, but is it
> there now?
I believe the consensus is that this feature could never be implemented.
To do it correctly, everytime you did an svn up or svn ci, Subversion
would have to process your entire WC looking for files that have this
keyword associated with them. And it would have to do so even for people
not using the keyword at all, unless there were some kind of global
configuration setting.
> If not, has anyone written a hook script to have the same effect? For
> example, I'd like a script that did the following:
>
> If there's a commit to the trunk, then before acting on it, the script
> would write something (the new revision number, if that's available,
> or maybe just a timestamp) to a version file, and add that file to the
> commit. If the commit is to a branch, it would write to the file in
> that branch.
I do not think this can be done in a hook script. I think what you would
want to do is the pretty much the same thing, except do it on the client.
Create a "svn-commit" script that your users use instead of svn ci. The
script would do something to update a file, or a property on that file and
then run svn ci. That would cause that file to be included in the commit,
and would allow you to then use the LastChangedRevision keyword in that
file.
The one thing I have not seen, is why it is so necessary to have this
information in a file to begin with? Why can't you just use a more normal
release process and use Tags for your releases?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org