You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Peter Childs <bl...@blueyonder.co.uk> on 2003/09/05 14:52:32 UTC
Current Updated Revision Number
How do I get last revision number for my repository. The keywords
only seam to handle when that file was last changed. What I would like to
do is see the revision number on the repository and then use it in my
code to see who which version a user is using.
So I can then commit, compile, and have my source code
auto-versioned...
Is this possible and if so how?
Peter Childs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
>>>> Peter Childs wrote:
>>>> How do I get last revision number for my repository. The keywords
>>>> only seam to handle when that file was last changed. What I would like
to
>>>> do is see the revision number on the repository and then use it in my
>>>> code to see who which version a user is using.
>>>> So I can then commit, compile, and have my source code
>>>> auto-versioned...
>> On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>>> you might use the svnversion command to do this:
>>> compile using gcc -DVERSION=`svnversion .`
>>> There currently is no keyword which is substituted with the output from
>>> svnversion.
> On Fri, 5 Sep 2003, Peter Childs wrote:
>> Super a keyword might be useful one day however.... maybe a TODO
>> is in order.
Bill Comisky wrote:
> I didn't see any issues pertaining to the single-revision-working-copy
> revision keyword. I've seen this pop up on the list several times,
> and personally am interested in this feature. Would it be reasonable to
> file an "enhancement" issue for this?
Implementing such a keyword would require significant special case
behaviour: Subversion would have to update files containing this keyword
every time the repo revision changed, even though the file contents in the
repo had not.
It would be wise to discuss on dev@ whether such special-casing would ever
be acceptable, before filing an issue.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
>>>> Peter Childs wrote:
>>>> How do I get last revision number for my repository. The keywords
>>>> only seam to handle when that file was last changed. What I would like
to
>>>> do is see the revision number on the repository and then use it in my
>>>> code to see who which version a user is using.
>>>> So I can then commit, compile, and have my source code
>>>> auto-versioned...
>> On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>>> you might use the svnversion command to do this:
>>> compile using gcc -DVERSION=`svnversion .`
>>> There currently is no keyword which is substituted with the output from
>>> svnversion.
> On Fri, 5 Sep 2003, Peter Childs wrote:
>> Super a keyword might be useful one day however.... maybe a TODO
>> is in order.
Bill Comisky wrote:
> I didn't see any issues pertaining to the single-revision-working-copy
> revision keyword. I've seen this pop up on the list several times,
> and personally am interested in this feature. Would it be reasonable to
> file an "enhancement" issue for this?
Implementing such a keyword would require significant special case
behaviour: Subversion would have to update files containing this keyword
every time the repo revision changed, even though the file contents in the
repo had not.
It would be wise to discuss on dev@ whether such special-casing would ever
be acceptable, before filing an issue.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Bill Comisky <bc...@pobox.com>.
On Fri, 5 Sep 2003, Ben Collins-Sussman wrote:
> Bill Comisky <bc...@pobox.com> writes:
>
> > I didn't see any issues pertaining to the single-revision-working-copy
> > revision keyword. I've seen this pop up on the list several times,
> > and personally am interested in this feature. Would it be reasonable to
> > file an "enhancement" issue for this?
>
> You mean issue 1287? :-)
I don't think so, that issue looks to me like it is for another alias
(Revision) for the LastChangedRevision keyword. From issue 1287:
"Currently, Subversion supports the keyword "LastChangedRevision" along
with the short form "Rev". In CVS this was called "Revision", so this
should also be supported for backwards compatility."
bill
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Bill Comisky <bc...@pobox.com>.
On Fri, 5 Sep 2003, Ben Collins-Sussman wrote:
> Bill Comisky <bc...@pobox.com> writes:
>
> > I didn't see any issues pertaining to the single-revision-working-copy
> > revision keyword. I've seen this pop up on the list several times,
> > and personally am interested in this feature. Would it be reasonable to
> > file an "enhancement" issue for this?
>
> You mean issue 1287? :-)
I don't think so, that issue looks to me like it is for another alias
(Revision) for the LastChangedRevision keyword. From issue 1287:
"Currently, Subversion supports the keyword "LastChangedRevision" along
with the short form "Rev". In CVS this was called "Revision", so this
should also be supported for backwards compatility."
bill
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Ben Collins-Sussman <su...@collab.net>.
Bill Comisky <bc...@pobox.com> writes:
> I didn't see any issues pertaining to the single-revision-working-copy
> revision keyword. I've seen this pop up on the list several times,
> and personally am interested in this feature. Would it be reasonable to
> file an "enhancement" issue for this?
You mean issue 1287? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Ben Collins-Sussman <su...@collab.net>.
Bill Comisky <bc...@pobox.com> writes:
> I didn't see any issues pertaining to the single-revision-working-copy
> revision keyword. I've seen this pop up on the list several times,
> and personally am interested in this feature. Would it be reasonable to
> file an "enhancement" issue for this?
You mean issue 1287? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Bill Comisky <bc...@pobox.com>.
On Fri, 5 Sep 2003, Peter Childs wrote:
> On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>
> > you might use the svnversion command to do this:
> >
> > compile using gcc -DVERSION=`svnversion .`
> >
> > There currently is no keyword which is substituted with the output from
> > svnversion.
>
> Super a keyword might be useful one day however.... maybe a TODO
> is in order.
>
> Peter Childs
I didn't see any issues pertaining to the single-revision-working-copy
revision keyword. I've seen this pop up on the list several times,
and personally am interested in this feature. Would it be reasonable to
file an "enhancement" issue for this?
The 'svnversion' workaround isn't as attractive when you can't embed its
output in a file as part of a build process (i.e. when there is no build
process, for non-compiled languages or other).
bill
[original question below for reference]
> > > How do I get last revision number for my repository. The keywords
> > > only seam to handle when that file was last changed. What I would like to
> > > do is see the revision number on the repository and then use it in my
> > > code to see who which version a user is using.
> > > So I can then commit, compile, and have my source code
> > > auto-versioned...
> > >
> > > Is this possible and if so how?
> > >
> > > Peter Childs
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Bill Comisky <bc...@pobox.com>.
On Fri, 5 Sep 2003, Peter Childs wrote:
> On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>
> > you might use the svnversion command to do this:
> >
> > compile using gcc -DVERSION=`svnversion .`
> >
> > There currently is no keyword which is substituted with the output from
> > svnversion.
>
> Super a keyword might be useful one day however.... maybe a TODO
> is in order.
>
> Peter Childs
I didn't see any issues pertaining to the single-revision-working-copy
revision keyword. I've seen this pop up on the list several times,
and personally am interested in this feature. Would it be reasonable to
file an "enhancement" issue for this?
The 'svnversion' workaround isn't as attractive when you can't embed its
output in a file as part of a build process (i.e. when there is no build
process, for non-compiled languages or other).
bill
[original question below for reference]
> > > How do I get last revision number for my repository. The keywords
> > > only seam to handle when that file was last changed. What I would like to
> > > do is see the revision number on the repository and then use it in my
> > > code to see who which version a user is using.
> > > So I can then commit, compile, and have my source code
> > > auto-versioned...
> > >
> > > Is this possible and if so how?
> > >
> > > Peter Childs
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Peter Childs <Bl...@blueyonder.co.uk>.
On Saturday 06 September 2003 19:15, Jack Repenning wrote:
> At 4:13 PM +0100 9/5/03, Peter Childs wrote:
> >On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
> >> you might use the svnversion command to do this:
> >>
> >> compile using gcc -DVERSION=`svnversion .`
> >>
> >> There currently is no keyword which is substituted with the output from
> >> svnversion.
> >
> > Super a keyword might be useful one day however.... maybe a TODO
> >is in order.
>
> Certainly, this idea is getting common enough to deserve a FAQ entry
> (with e.huelsmann's workaround, very likely).
>
> It seems to me (to many of us) that treating this info as a keyword
> creates more problems than it solves. I wonder, if you don't mind,
> if you could explain a bit more of why you want this, and why you're
> not concerned about the problems it engenders?
One of the main gains of Subversion over CVS is that it stores the repository
as a whole not just as changes of individual files. This means SVN has
abilities that many version control management systems do not have. Probably
the main reason we are thinking of transferring from CVS :)
Once you have checked out the repository you need to know what version have a
got. In our case of programming with it we would like to put the revision
number into the executable which is compiled from all the files in the
repository but because its generated it is not stored in the repository.
Then when someone reports a bug they can tell us the version number and we
can rewind the subversion (or recheck it out) with that revision and find the
bug therefore being a to check its existence and b to check if its been fixed
in a later version.
By using subversions revision numbers this can be done automatically without
us having to remember to update a file everytime we commit.
I can see the technical difficulties but I think the advantages out way the
difficulties (personally).
>
> Here's a partial list of those problems:
> * any file containing this keyword would have to be changed (by SVN)
> every time you update, even if the file itself had not changed.
Point taken. Our subversion is slow enough already.
> * The indication is ambiguous, since a given revision number actually
> applies to many complete project versions, in trunk/, tags/*/, and
> branches/*/.
Should not make any difference its no worse that using a date like samba do.
> * Updates of anything other than the whole working copy/build tree at
> once make this very weird--if you update some subdirectory that does
> *not* contain this file, ought this file also to be updated?
Intresting point. That does seam like a major problem.
> * And commits present that same problem in an even worse way, since
> committing a change by definition advances the repository revision,
> and yet does not give you the changes to all the files you're not
> committing.
Which is actually an announce that I've noticed so far. I usually end up
doing a update commit update sequence to get things in. maybe resolving
conflicts if necessary. (Fortinally we only have a development team of 3
currently)
I hope that helps.
Peter Childs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
e.huelsmann@gmx.net wrote:
> David,
>
> Although I understand your position, I am thinking of my situation:
>
> I build subversion from trunk almost three times a week. In this case
> there is a build process, so that the -DVERSION="`svnversion .`"
> solution works, but it is this kind of situations (but without the build)
> that I am thinking of...
I can see how you might have a situation without a build (non-compiled
languages), but even so, there will still be some kind of installer/packager
where svnversion can be invoked - won't there?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by e....@gmx.net.
David,
Although I understand your position, I am thinking of my situation:
I build subversion from trunk almost three times a week. In this case
there is a build process, so that the -DVERSION="`svnversion .`"
solution works, but it is this kind of situations (but without the build)
that I am thinking of...
bye,
Erik
> It might just be my opinion, but...
>
> I think this is a very overengineered solution to a problem, and will
> add lots of additional complexity in the working copy code.
>
> If the point is to have a version for customer/user reporting, why not
> base it on repository path rather than revision number? Is making a tag
> and switching over to it really that hard? With a tag you are reporting
> every version of every file, and tagging implies a release process.
>
> Developers who insist on giving customers/users non-tagged code which is
> potentially from a mixed-revision repository should just write a script
> to supply the version number during their deployment through svnversion.
>
> Am I missing something?
>
> -David Waite
>
> e.huelsmann@gmx.net wrote:
>
> >>>Suppose the file with the expandable keyword is "conf/revfile" (below
> >>>trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
>
> >>>build a release that includes one patch, the buildmeister does:
> >>>
> >>> cd trunk/ # or branches/whatever, or ....
> >>> svn up -r 1234 # includes conf/revfile, so it gets 1234
> >>> svn up -r 2345 src # excludes conf/revfile, so it doesn't
> change?
> >>>
> >>>Now revfile says "1234", but svnversion on "." would say "1234:2345",
> >>>which I think is not what anyone would want.
> >>>
> >>>
> >>That is just the same as if you had a manually maintained "VERSION.TXT"
> >>file in the root of the project, and updated only a sub-tree.
> VERSION.TXT
> >>would be out of date. If you put VERSION.TXT in the sub-tree, then it
> >>
> >>
> >would
> >
> >
> >>have been updated ... regardless of whether it was manually maintained
> or
> >>using this new keyword. The system works exactly as designed and as
> >>expected. I think that is reasonable behaviour.
> >>
> >>
> >
> >Yay Julian! Go!
> >
> >Well on a serious note: This is what I wanted to add to subversion when I
> >first started hacking it. (Only a few months ago) I never got round to
> doing
> >it,
> >but I do think this is reasonable, especially where the argument of the
> >keyword
> >is '.'.
> >
> >bye,
> >
> >
> >Erik.
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Jack Repenning <jr...@collab.net>.
At 12:32 PM +0100 9/9/03, Julian Foad wrote:
>Jack Repenning wrote:
>>
>>Hmmm ... but if we had some "keyword svn:reporevision" voodoo such
>>as we're discussing, that wouldn't work for your "write-only repo"
>>scenario either, would it? If you never update, the voodoo file
>>never gets updated..... unless we also require it to be updated by
>>any operation that changes the `svnversion` of the wc?
>
>Yup - quite true - bad example - not thinking clearly. Still, the
>point was that many people use Subversion in a very simplistic way...
Well, sure they do. But the point here is, this simplistic idea
doesn't seem to be congealing into a simplistic implementation ;-\.
It may be, in this case, that the simplistic users have to do a bit
of not-so-simplistic choosing among viable options.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Julian Foad <ju...@btopenworld.com>.
Jack Repenning wrote:
> At 12:22 AM +0100 9/9/03, Julian Foad wrote:
>
>> I think this discussion applies to people who do not "release"
>> anything but just use Subversion in a very simple way. For instance,
>> I have some of my source files stored in a local repository, and all I
>> do most of the time is commit changes:
>>
>> ~> # edit, compile, test ...
>> ~> svn commit -m "Changed blah..."
>> ~> # edit, compile, test ...
>> ~> svn commit -m "Fixed blah..."
>> ...
>>
>> I do not even "update", because no-one else accesses this repository
>> so my working copy is always up to date anyway. If I were to want a
>> tag for each commit, which is the sort of scenario that we are talking
>> about, then I would want a script to use in place of "svn commit"
>> that, as well as doing the commit, chose a tag name and created the tag.
>
> Hmmm ... but if we had some "keyword svn:reporevision" voodoo such as
> we're discussing, that wouldn't work for your "write-only repo" scenario
> either, would it? If you never update, the voodoo file never gets
> updated..... unless we also require it to be updated by any operation
> that changes the `svnversion` of the wc?
Yup - quite true - bad example - not thinking clearly. Still, the point was that many people use Subversion in a very simplistic way...
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Jack Repenning <jr...@collab.net>.
At 12:22 AM +0100 9/9/03, Julian Foad wrote:
>
>I think this discussion applies to people who do not "release"
>anything but just use Subversion in a very simple way. For
>instance, I have some of my source files stored in a local
>repository, and all I do most of the time is commit changes:
>
>~> # edit, compile, test ...
>~> svn commit -m "Changed blah..."
>~> # edit, compile, test ...
>~> svn commit -m "Fixed blah..."
>...
>
>I do not even "update", because no-one else accesses this repository
>so my working copy is always up to date anyway. If I were to want a
>tag for each commit, which is the sort of scenario that we are
>talking about, then I would want a script to use in place of "svn
>commit" that, as well as doing the commit, chose a tag name and
>created the tag.
Hmmm ... but if we had some "keyword svn:reporevision" voodoo such as
we're discussing, that wouldn't work for your "write-only repo"
scenario either, would it? If you never update, the voodoo file
never gets updated..... unless we also require it to be updated by
any operation that changes the `svnversion` of the wc?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Julian Foad <ju...@btopenworld.com>.
David Waite wrote:
[in response to a proposal for a keyword that behaves like "svnversion"]
>
> I think this is a very overengineered solution to a problem, and will
> add lots of additional complexity in the working copy code.
Maybe. Certainly I cannot see a good (simple) implementation yet, and I would not want to see it implemented in a very complex way.
> If the point is to have a version for customer/user reporting, why not
> base it on repository path rather than revision number? Is making a tag
> and switching over to it really that hard?
That is surely a Good Thing to do. It is harder than just having a keyword which gets updated by Subversion, but it is not Very Hard. For one thing, someone or something has to think of a new name for each new tag. The question is: Will most users find this an acceptable method? Can we help to make it acceptable, by providing example scripts, tag naming suggestions, etc.? Yes, I think we can.
> With a tag you are reporting every version of every file,
Yes - a tag gives a precise identification even from a mixed-revision WC, whereas "svnversion" would have just said "this is a mixture of revisions between X and Y", which is not enough information to reconstruct the working copy later.
> and tagging implies a release process.
It does. That's fine for people who are accustomed to having a release process. I think this discussion applies to people who do not "release" anything but just use Subversion in a very simple way. For instance, I have some of my source files stored in a local repository, and all I do most of the time is commit changes:
~> # edit, compile, test ...
~> svn commit -m "Changed blah..."
~> # edit, compile, test ...
~> svn commit -m "Fixed blah..."
...
I do not even "update", because no-one else accesses this repository so my working copy is always up to date anyway. If I were to want a tag for each commit, which is the sort of scenario that we are talking about, then I would want a script to use in place of "svn commit" that, as well as doing the commit, chose a tag name and created the tag. Could we offer something like these as suggestions:
~/bin/commit-myproj:
[[[
#!/bin/bash
# Commit "~/src/myproj" and tag it.
# Usage: commit-myproj [-m COMMIT-MSG | -F COMMIT_MSG_FILE]
REPOS_URL=file://`echo ~`/vcs/myrepos
svn commit $* ~/src/myproj
svn update ~/src/myproj
TAG=date-`date +%Y%m%d%H%M%S` # date/time stamp
#TAG=rev-`svnversion ~/src/myproj` # WC base revision
#TAG=tag-`svn ls $REPOS_URL/myproj/tags | wc -l` # sequence number 0,1,2,...
svn cp $REPOS_URL/myproj/trunk $REPOS_URL/myproj/tags/$TAG
]]]
commit-myproj.bat:
[[[
@echo off
rem Commit "~/src/myproj" and tag it.
rem Usage: commit-myproj [-m COMMIT-MSG | -F COMMIT_MSG_FILE]
set REPOS_URL="file:///%HOME%/vcs/myrepos"
svn commit %* %HOME%/src/myproj
svn update %HOME%/src/myproj
rem Tag name: date/time stamp, WC base revision, or sequence number 0,1,2,...
set TAG=???
svn cp %REPOS_URL%/myproj/trunk %REPOS_URL%/myproj/tags/$TAG
]]]
Someone with Windows/DOS knowledge would need to fill in the "set TAG=" examples.
> Developers who insist on giving customers/users non-tagged code which is
> potentially from a mixed-revision repository should just write a script
> to supply the version number during their deployment through svnversion.
Yes, that should be acceptable.
> Am I missing something?
I don't know. I am missing something: a grasp of how easy or hard it might be to provide a minimal-effort solution for minimalist users.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by David Waite <ma...@akuma.org>.
It might just be my opinion, but...
I think this is a very overengineered solution to a problem, and will
add lots of additional complexity in the working copy code.
If the point is to have a version for customer/user reporting, why not
base it on repository path rather than revision number? Is making a tag
and switching over to it really that hard? With a tag you are reporting
every version of every file, and tagging implies a release process.
Developers who insist on giving customers/users non-tagged code which is
potentially from a mixed-revision repository should just write a script
to supply the version number during their deployment through svnversion.
Am I missing something?
-David Waite
e.huelsmann@gmx.net wrote:
>>>Suppose the file with the expandable keyword is "conf/revfile" (below
>>>trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
>>>build a release that includes one patch, the buildmeister does:
>>>
>>> cd trunk/ # or branches/whatever, or ....
>>> svn up -r 1234 # includes conf/revfile, so it gets 1234
>>> svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
>>>
>>>Now revfile says "1234", but svnversion on "." would say "1234:2345",
>>>which I think is not what anyone would want.
>>>
>>>
>>That is just the same as if you had a manually maintained "VERSION.TXT"
>>file in the root of the project, and updated only a sub-tree. VERSION.TXT
>>would be out of date. If you put VERSION.TXT in the sub-tree, then it
>>
>>
>would
>
>
>>have been updated ... regardless of whether it was manually maintained or
>>using this new keyword. The system works exactly as designed and as
>>expected. I think that is reasonable behaviour.
>>
>>
>
>Yay Julian! Go!
>
>Well on a serious note: This is what I wanted to add to subversion when I
>first started hacking it. (Only a few months ago) I never got round to doing
>it,
>but I do think this is reasonable, especially where the argument of the
>keyword
>is '.'.
>
>bye,
>
>
>Erik.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by e....@gmx.net.
> > Suppose the file with the expandable keyword is "conf/revfile" (below
> > trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
> > build a release that includes one patch, the buildmeister does:
> >
> > cd trunk/ # or branches/whatever, or ....
> > svn up -r 1234 # includes conf/revfile, so it gets 1234
> > svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
> >
> > Now revfile says "1234", but svnversion on "." would say "1234:2345",
> > which I think is not what anyone would want.
>
> That is just the same as if you had a manually maintained "VERSION.TXT"
> file in the root of the project, and updated only a sub-tree. VERSION.TXT
> would be out of date. If you put VERSION.TXT in the sub-tree, then it
would
> have been updated ... regardless of whether it was manually maintained or
> using this new keyword. The system works exactly as designed and as
> expected. I think that is reasonable behaviour.
Yay Julian! Go!
Well on a serious note: This is what I wanted to add to subversion when I
first started hacking it. (Only a few months ago) I never got round to doing
it,
but I do think this is reasonable, especially where the argument of the
keyword
is '.'.
bye,
Erik.
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Jack Repenning <jr...@collab.net>.
At 8:11 PM +0100 9/8/03, Julian Foad wrote:
>> cd trunk/ # or branches/whatever, or ....
>> svn up -r 1234 # includes conf/revfile, so it gets 1234
>> svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
>>
>>Now revfile says "1234", but svnversion on "." would say
>>"1234:2345", which I think is not what anyone would want.
>
>That is just the same as if you had a manually maintained
>"VERSION.TXT" file in the root of the project, and updated only a
>sub-tree. VERSION.TXT would be out of date. If you put VERSION.TXT
>in the sub-tree, then it would have been updated ... regardless of
>whether it was manually maintained or using this new keyword. The
>system works exactly as designed and as expected. I think that is
>reasonable behaviour.
Depends on what "manually maintained" means.
The system that seems sensible to me is to compute the version info
(i.e., run svnversion) at the time you build the system (or otherwise
decide it's final, whatever that means if it's a directory tree that
doesn't get "built"). So, if there's a makefile, you might use
"REV=`svnversion`", and possibly a forcing production to ensure that
one file is rebuilt whenever you build anything. Or, if it's a web
tree, then the script you use to export it to the htdocs directory
would also run "svnversion > VERSION.TXT".
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Julian Foad <ju...@btopenworld.com>.
Jack Repenning wrote:
> At 2:16 PM +0100 9/8/03, Julian Foad wrote:
>
>> (b) the WC base revision, as given by "svnversion". A keyword based
>> on "svnversion", with its argument restricted to parent (grandparent,
>> ...) directory of the file in which it appears
>
> Hmmm ... that depth would have to be user-settable, right? So either
> the keyword includes the target to use
>
> $SvnRevision:../../..:$ non-expanded
> $SvnRevision:../../..:6329-9654$ expanded
>
> or maybe the svn:keywords value that specifies to expand this one would
> also name the target
>
> $SvnRevision$
> $SvnRevision: 6329-9654$
>
> svn pset svn:keywords SvnRevision:../../.. thatfile
>
> Something along those lines?
Yes, something along those lines.
>> At first I thought the problem was that the file ought to be updated
>> even when it is not in the (implicit or explicit) list of files to be
>> updated. But that is not a problem: the file will always be in the
>> list during a recursive update of any of its parents, and in
>> non-recursive update that does not include this file, it will not be
>> updated. That makes sense.
>
> I'm not sure it makes sense to me. More to the point, does it make
> sense to the people who want this?
>
> Suppose the file with the expandable keyword is "conf/revfile" (below
> trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
> build a release that includes one patch, the buildmeister does:
>
> cd trunk/ # or branches/whatever, or ....
> svn up -r 1234 # includes conf/revfile, so it gets 1234
> svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
>
> Now revfile says "1234", but svnversion on "." would say "1234:2345",
> which I think is not what anyone would want.
That is just the same as if you had a manually maintained "VERSION.TXT" file in the root of the project, and updated only a sub-tree. VERSION.TXT would be out of date. If you put VERSION.TXT in the sub-tree, then it would have been updated ... regardless of whether it was manually maintained or using this new keyword. The system works exactly as designed and as expected. I think that is reasonable behaviour.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Jack Repenning <jr...@collab.net>.
At 2:16 PM +0100 9/8/03, Julian Foad wrote:
>
>(b) the WC base revision, as given by "svnversion". A keyword based
>on "svnversion", with its argument restricted to parent
>(grandparent, ...) directory of the file in which it appears
Hmmm ... that depth would have to be user-settable, right? So either
the keyword includes the target to use
$SvnRevision:../../..:$ non-expanded
$SvnRevision:../../..:6329-9654$ expanded
or maybe the svn:keywords value that specifies to expand this one
would also name the target
$SvnRevision$
$SvnRevision: 6329-9654$
svn pset svn:keywords SvnRevision:../../.. thatfile
Something along those lines?
>At first I thought the problem was that the file ought to be updated
>even when it is not in the (implicit or explicit) list of files to
>be updated. But that is not a problem: the file will always be in
>the list during a recursive update of any of its parents, and in
>non-recursive update that does not include this file, it will not be
>updated. That makes sense.
I'm not sure it makes sense to me. More to the point, does it make
sense to the people who want this?
Suppose the file with the expandable keyword is "conf/revfile" (below
trunk/ or tags/whatever/ or branches/whatever/, as the case may be).
To build a release that includes one patch, the buildmeister does:
cd trunk/ # or branches/whatever, or ....
svn up -r 1234 # includes conf/revfile, so it gets 1234
svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
Now revfile says "1234", but svnversion on "." would say "1234:2345",
which I think is not what anyone would want.
>The problem is that the file(s) with the keyword cannot be correctly
>updated until all of the other files have been updated, or at least
>until their new revision number is known.
Mmmm ... an excellent point I had not considered.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Julian Foad <ju...@btopenworld.com>.
Jack Repenning wrote:
> At 4:13 PM +0100 9/5/03, Peter Childs wrote:
>
>> On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>>
>>> you might use the svnversion command to do this:
>>>
>>> compile using gcc -DVERSION=`svnversion .`
>>>
>>> There currently is no keyword which is substituted with the output from
>>> svnversion.
>>
>> Super a keyword might be useful one day however.... maybe a TODO
>> is in order.
>
> Certainly, this idea is getting common enough to deserve a FAQ entry
> (with e.huelsmann's workaround, very likely).
>
> It seems to me (to many of us) that treating this info as a keyword
> creates more problems than it solves.
Depends on whether "this info" is:
(a) the latest revision of the repository. Yes. All the problems you described apply.
(b) the WC base revision, as given by "svnversion". A keyword based on "svnversion", with its argument restricted to parent (grandparent, ...) directory of the file in which it appears, solves most of those problems:
> * any file containing this keyword would have to be changed (by SVN)
> every time you update, even if the file itself had not changed.
At first I thought the problem was that the file ought to be updated even when it is not in the (implicit or explicit) list of files to be updated. But that is not a problem: the file will always be in the list during a recursive update of any of its parents, and in non-recursive update that does not include this file, it will not be updated. That makes sense.
The problem is that the file(s) with the keyword cannot be correctly updated until all of the other files have been updated, or at least until their new revision number is known. This makes the implementation awkward, especially in the case of a partial (aborted) update.
> * The indication is ambiguous, since a given revision number actually
> applies to many complete project versions, in trunk/, tags/*/, and
> branches/*/.
Solved: applies to a specific sub-tree.
> * Updates of anything other than the whole working copy/build tree at
> once make this very weird--if you update some subdirectory that does
> *not* contain this file, ought this file also to be updated?
Solved: mixed-revision WC gives mixed-revision output string.
> * And commits present that same problem in an even worse way, since
> committing a change by definition advances the repository revision, and
> yet does not give you the changes to all the files you're not committing.
Solved: this is a mixed-revision WC.
...
> For such reasons, it seems to us that this annotation *belongs* in the
> build system (as suggested by e.huelsmann), where local needs,
> assumptions, practices, and policies are known, and the annotation
> mechanics can be tweaked accordingly.
I'm half in agreement, as the semantics of an "svnversion" keyword don't fit as cleanly as the other keywords, but many uses of Subversion don't include a build system. I suppose they could always be given one, e.g. a wrapper that runs "svn" and then "svnversion" and puts the output of "svnversion" into an appropriate file, but there are down sides to that (e.g. portability).
I would support the addition of a keyword based on "svnversion" semantics if people can come up with a reasonable implementation for it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Jack Repenning <jr...@collab.net>.
At 4:13 PM +0100 9/5/03, Peter Childs wrote:
>On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>
>> you might use the svnversion command to do this:
>>
>> compile using gcc -DVERSION=`svnversion .`
>>
>> There currently is no keyword which is substituted with the output from
>> svnversion.
>
> Super a keyword might be useful one day however.... maybe a TODO
>is in order.
Certainly, this idea is getting common enough to deserve a FAQ entry
(with e.huelsmann's workaround, very likely).
It seems to me (to many of us) that treating this info as a keyword
creates more problems than it solves. I wonder, if you don't mind,
if you could explain a bit more of why you want this, and why you're
not concerned about the problems it engenders?
Here's a partial list of those problems:
* any file containing this keyword would have to be changed (by SVN)
every time you update, even if the file itself had not changed.
* The indication is ambiguous, since a given revision number actually
applies to many complete project versions, in trunk/, tags/*/, and
branches/*/.
* Updates of anything other than the whole working copy/build tree at
once make this very weird--if you update some subdirectory that does
*not* contain this file, ought this file also to be updated?
* And commits present that same problem in an even worse way, since
committing a change by definition advances the repository revision,
and yet does not give you the changes to all the files you're not
committing.
To thread that all into a coherent story, suppose your project has
been under development and maintenance for some time, and you have
project/trunk/* the active working stuff
project/tags/REL1/* the stuff you sent to customers as release 1
project/branches/REL2/* the Release 2 stuff, nearing release and
branched for stabilization
project/branches/patches/REL1.1.* new work to fix a bug just found in REL1
Now when the maintenance engineer commits a change to
REL1.1/src/foo.c, that bumps the revision number for the whole
repository. But it has nothing to do with the other areas. If the
release engineeer building the branches/REL2/* nightly builds runs
"svn up", then things get incremented and rebuilt, even though no
changes have happened to the REL2 sources--quite the opposite of what
you want during "stabilization!"
For such reasons, it seems to us that this annotation *belongs* in
the build system (as suggested by e.huelsmann), where local needs,
assumptions, practices, and policies are known, and the annotation
mechanics can be tweaked accordingly.
In a similar vein: is there some existing VC system that does
something like this for you? I'm not familiar with that. If so,
maybe a description of how it manages this, and how you use it, would
help us understand. Maybe this idea comes from some fundamentally
different development model than I used above? For example, I could
see it a bit more in the "thousand points of light" repository galaxy
model of BitKeeper and Arch, where you would more or less expect the
repository revision to reflect only your own local fragment of the
whole.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by Peter Childs <bl...@blueyonder.co.uk>.
On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
> you might use the svnversion command to do this:
>
> compile using gcc -DVERSION=`svnversion .`
>
> There currently is no keyword which is substituted with the output from
> svnversion.
Super a keyword might be useful one day however.... maybe a TODO
is in order.
Peter Childs
>
> bye,
>
> Erik.
>
> > How do I get last revision number for my repository. The keywords
> > only seam to handle when that file was last changed. What I would like to
> > do is see the revision number on the repository and then use it in my
> > code to see who which version a user is using.
> > So I can then commit, compile, and have my source code
> > auto-versioned...
> >
> > Is this possible and if so how?
> >
> > Peter Childs
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by e....@gmx.net.
you might use the svnversion command to do this:
compile using gcc -DVERSION=`svnversion .`
There currently is no keyword which is substituted with the output from
svnversion.
bye,
Erik.
> How do I get last revision number for my repository. The keywords
> only seam to handle when that file was last changed. What I would like to
> do is see the revision number on the repository and then use it in my
> code to see who which version a user is using.
> So I can then commit, compile, and have my source code
> auto-versioned...
>
> Is this possible and if so how?
>
> Peter Childs
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Current Updated Revision Number
Posted by John Peacock <jp...@rowman.com>.
Peter Childs wrote:
> How do I get last revision number for my repository. The keywords
> only seam to handle when that file was last changed. What I would like to
> do is see the revision number on the repository and then use it in my
> code to see who which version a user is using.
> So I can then commit, compile, and have my source code
> auto-versioned...
As long as you have only one project per repository, this will do more or less
what you intend. However, I want to remind you that the last revision number is
a global repository value. If you have 10 projects in a repository, the last
revision number is only meaningfully related to the last commit on any of those
projects. The SVN revision number is only a monotonically increasing number
associated with the number of commits made to a repository. In this sense, the
last revision number is even less suitable to be used as a file or project
VERSION than the CVS revision number used to be.
I am working on a Perl solution which would include a script (called 'release'),
which would update the master $VERSION for a given project (in whatever file
that may be located), then optionally test, tag, and build a tarfile. I'm
having a severe lack of tuits recently, so it is merely pencil scratches on the
back of a page right now, but I do know how I am going to do it.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org