You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mats Nilsson <ma...@xware.se> on 2002/07/31 13:03:48 UTC
Feature request: Keyword $Rev$ with a twist
Hi
$Rev$ expands to the revision in which the file last changed.
I'm requesting another keyword that expands to the *currently checked out
revision* for that file. That way it will be easier to get the
build-revision into the resulting binaries, without having to resort to
change a file every time.
I guess I could extract that info from the 'svn co' output - but that would
IMO be less satisfactory, since it would require me to make 'svn co' part of
the build procedure.
What do you think?
Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Dave Cridland <da...@cridland.net>.
On Mon, 2002-08-05 at 07:40, Mats Nilsson wrote:
> The trouble of doing a combination of 'svn info' and 'sed' to patch the
> source code as a build step, is that svn will not recognize these changes
> as simple keyword substitutions. It will think that the file has changed,
> even though it hasn't (in a logical sense), and the file will get checked
> in in a changed state, upset merges and diffs and whatnot.
For what it's worth, I'm perfectly happy with the file being generated
from a script as part of my source-release procedure. This is what
happens with your ./configure script, after all - when you create the
source release, you run autoconf/automake/etc to create it. The file
need not be placed in the svn repository at all, just as ./configure
isn't.
For what it's worth, the only thing I would like to see to aid
auto-builds is some form of "svn info --revision" or "svn info
--format='%{REVISION}'" or similar. I have no preference as to which,
although the latter would probably be easier for Windows folks, and
makes no difference to UNIX folks. Either is, of course, not essential.
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Mats Nilsson <ma...@xware.se>.
>+1 on your -1, especially as there's no guarantee that all of the
>working copy is at that revision. Anyway, you can get almost the same
>effect by "svn ci --force -m 'Bump revision for baseline'"'ing your
>version.h file that has a $Rev$ keyword in it.
Consider a shop where we build regularly, say continuously, a majority of a
repository's revisions would be of this kind. Clearly not favourable.
The trouble of doing a combination of 'svn info' and 'sed' to patch the
source code as a build step, is that svn will not recognize these changes
as simple keyword substitutions. It will think that the file has changed,
even though it hasn't (in a logical sense), and the file will get checked
in in a changed state, upset merges and diffs and whatnot.
The point is simply that svn sits on all information. It would be logical
to introduce this feature within svn instead of around it. And probably
less error prone too.
Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by br...@xbc.nu.
Greg Hudson wrote:
>On Sat, 2002-08-03 at 21:35, Martin Pool wrote:
>
>
>>Suppose I have version.h in my working copy, and I svn up to get new
>>changes. version.h has not actually had any changes committed, but my
>>local copy changes to get the new $WorkingRev$. Presumably its mtime
>>needs to get updated to the current time.
>>
>>
>
>Presumably if we had this feature, we would have a flag in entries.h
>which means "the text-base of this file contains $WorkingRev$". If the
>flag was set, we would know to regenerate the working contents of the
>file each time an update is done.
>
Nah, it should be enough to notice that WorkingRev is listed in
svn:keywords.
>Of course, the complexity involved here is pretty high for a feature
>which is nothing more than a neat trick to simplify build systems a
>little bit. So I'm -1 on having $WorkingRev$.
>
>
+1 on your -1, especially as there's no guarantee that all of the
working copy is at that revision. Anyway, you can get almost the same
effect by "svn ci --force -m 'Bump revision for baseline'"'ing your
version.h file that has a $Rev$ keyword in it.
--
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: Feature request: Keyword $Rev$ with a twist
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2002-08-03 at 21:35, Martin Pool wrote:
> Suppose I have version.h in my working copy, and I svn up to get new
> changes. version.h has not actually had any changes committed, but my
> local copy changes to get the new $WorkingRev$. Presumably its mtime
> needs to get updated to the current time.
Presumably if we had this feature, we would have a flag in entries.h
which means "the text-base of this file contains $WorkingRev$". If the
flag was set, we would know to regenerate the working contents of the
file each time an update is done.
Of course, the complexity involved here is pretty high for a feature
which is nothing more than a neat trick to simplify build systems a
little bit. So I'm -1 on having $WorkingRev$.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Martin Pool <mb...@toey.home>.
On 31 Jul 2002, Ben Collins-Sussman <su...@collab.net> wrote:
> William Uther <wi...@cs.cmu.edu> writes:
>
> > If I remember correctly, this has come up before. The issue is svn supports
> > mixed revision working copies (again, IIRC). You cannot guarantee that the
> > value in any file is up to date for any other file in the working copy. If
> > you add this keyword in the file revision.h, and then 'svn up' a dir that
> > doesn't contain revision.h, then revision.h will not be updated and will be
> > contain incorrect information.
>
> I think that we've all agreed that we don't want to put the
> working-rev into our Subversion's *own* svn_version.h header. But I
> don't think anyone is particularly against the creation of a
> $WorkingRev$ keyword.
Suppose I have version.h in my working copy, and I svn up to get new
changes. version.h has not actually had any changes committed, but my
local copy changes to get the new $WorkingRev$. Presumably its mtime
needs to get updated to the current time.
Excuse me if I'm confused, but that seems like quite a change from the
current CVS and Subversion behaviour, which is not to touch files that
have not changed in the repository.
So, if this change was accepted, would every file in the current
directory be updated? (Therefore, make will always rebuild everything
after svn up.) Or would only files containing $WorkingRev$ be
updated? That sounds a little wierd.
Or does the variable only get updated when the file is "really"
updated? So to be sure of getting the right version, I'd need to rm
and re-update the file.
I don't really object to the feature and I can see how it would be
useful, but I'm curious how it would work.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Thu, Aug 01, 2002 at 10:54:29AM -0500, Karl Fogel wrote:
> > But anyway, we already discussed this topic about two months ago and
> > agreed on leaving it as is for now and discuss it again after 1.0 is
> > out.
> So why are you bringing it up again now, during Alpha?
Originally, it was just a side note and then the thread ran out of
control =8}. Sorry! I promise to shut up on this topic until 1.0 is
out :)
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> There is no technical reason for the current behavior of cvs/svn, it
> is a _political_ decision.
>
> Maybe you could try again and give me a _real_ use case for mixed-revs?
> Please do not mis-understand me: I _know_ there are real use cases for
> mixed-revs. But I don't believe that those use-cases are so frequent
> that it is worth to burden the day-by-day use.
>
> But anyway, we already discussed this topic about two months ago and
> agreed on leaving it as is for now and discuss it again after 1.0 is
> out.
So why are you bringing it up again now, during Alpha?
What I'm really saying is: this list is active enough already, Josef.
If you openly acknowledge that a post is not constructive (as you do
above), then don't post on that topic at all, to save everyone else's
time.
Thank you,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by br...@xbc.nu.
Quoting Julian Fitzell <ju...@beta4.com>:
> Josef Wolf wrote:
> [...]
> > There is no technical reason for the current behavior of cvs/svn, it
> > is a _political_ decision.
> >
> > Maybe you could try again and give me a _real_ use case for
> mixed-revs?
> > Please do not mis-understand me: I _know_ there are real use cases
> for
> > mixed-revs. But I don't believe that those use-cases are so frequent
> > that it is worth to burden the day-by-day use.
>
> [...]
>
> I dunno, I sometimes have stable tagged versions of software checked out
>
> and then want to update just one file that I know has had some important
>
> bug fix made to it. Am I misunderstanding or doesn't that need
> mixed-revs?
This case absolutely requires mixed revs, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Mon, Aug 05, 2002 at 04:14:58AM -0700, Julian Fitzell wrote:
[ ... ]
> Sorry, to jump back in again so late (I was away for a long weekend) and
> I certainly don't want to carry on the argument just for the sake of it.
[ ... ]
I have promised Karl not to argue about this topic on the list until
1.0 is out, so I will answer this in a private mail.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Julian Fitzell <ju...@beta4.com>.
Josef Wolf wrote:
> On Thu, Aug 01, 2002 at 07:48:08AM -0700, Julian Fitzell wrote:
>
> [ ... ]
>
>>I usually end up updating to the next tagged revision eventually.
>>Sometimes I might be making local changes as well, some times not.
>
>
> This is _exactly_ the answer I expected! This means that your mixed WC
> is only a temporary state and you get rid of it when you are done
> instead of starting to commit/merge in this state.
>
> Given that it is only a temporary state and it is used seldom I repeat
> my claim: I don't believe that those use-cases are so frequent that it
> is worth to burden the day-by-day use.
Sorry, to jump back in again so late (I was away for a long weekend) and
I certainly don't want to carry on the argument just for the sake of it.
But, I should clarify that I don't consider it a temporary state. I
consider such a working copy to be constantly in a mixed state. It's
just that occasionaly, around a release date, the number of mixed
revisions happens to be 1. Undoubtedly I would continue to pull down
some new versions again once I've updated.
Again, this is only certain types of projects - the ones that I both
desire to keep working most of the time, want to stay relatively current
on, and want to tinker with myself.
Honestly, I don't personally care whether it's post-1.0 or not since
version numbers are just that - I'll use the product when it supports
everything I need. But I'm not sure I'd move over fully to subversion
until I was no longer being told I had to update all my files or none of
them.
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Thu, Aug 01, 2002 at 07:48:08AM -0700, Julian Fitzell wrote:
[ ... ]
> I usually end up updating to the next tagged revision eventually.
> Sometimes I might be making local changes as well, some times not.
This is _exactly_ the answer I expected! This means that your mixed WC
is only a temporary state and you get rid of it when you are done
instead of starting to commit/merge in this state.
Given that it is only a temporary state and it is used seldom I repeat
my claim: I don't believe that those use-cases are so frequent that it
is worth to burden the day-by-day use.
> I dunno, I can't I do it a *lot* but it's nice to be able to do and I
> would miss it coming from CVS.
OK, it is nice to _be_ _able_ to do such things. And I am the last one
to completely ban the possibility of mix-revs. My point is just that
the mix-rev-concept should not be _forced_ on the day-by-day use. The
problem is that the current behavior is _forcing_ you to deal with
mix-revs, no matter whether you want them or not.
But hey, let us stop this discussion at this point and start it over
when 1.0 is out.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Julian Fitzell <ju...@beta4.com>.
Josef Wolf wrote:
> On Thu, Aug 01, 2002 at 01:36:47AM -0700, Julian Fitzell wrote:
>
>>Josef Wolf wrote:
>>[...]
>>
>>>There is no technical reason for the current behavior of cvs/svn, it
>>>is a _political_ decision.
>>>
>>>Maybe you could try again and give me a _real_ use case for mixed-revs?
>>>Please do not mis-understand me: I _know_ there are real use cases for
>>>mixed-revs. But I don't believe that those use-cases are so frequent
>>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>>that it is worth to burden the day-by-day use.
>>
>>[...]
>>
>>I dunno, I sometimes have stable tagged versions of software checked out
>
> ^^^^^^^^^
>
>>and then want to update just one file that I know has had some important
>>bug fix made to it. Am I misunderstanding or doesn't that need mixed-revs?
>
>
> This is definitely a use case. But how often do you really do this?
> And what if this particular file has not only this particular bugfix
> but also some other changes? Why not _merge_ the bugfix onto the tagged
> version? You would need to merge anyway, when there are a lot of
> unrelated changes before the bugfix. What do you do with the WC after
> having this mixed state? Do you really go ahead and start to
> commit/merge/whatever? Or is this mixed state only temporary
> and you delete it after you are done with it?
>
I usually end up updating to the next tagged revision eventually.
Sometimes I might be making local changes as well, some times not.
I dunno, I can't I do it a *lot* but it's nice to be able to do and I
would miss it coming from CVS.
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Thu, Aug 01, 2002 at 01:36:47AM -0700, Julian Fitzell wrote:
> Josef Wolf wrote:
> [...]
> >There is no technical reason for the current behavior of cvs/svn, it
> >is a _political_ decision.
> >
> >Maybe you could try again and give me a _real_ use case for mixed-revs?
> >Please do not mis-understand me: I _know_ there are real use cases for
> >mixed-revs. But I don't believe that those use-cases are so frequent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >that it is worth to burden the day-by-day use.
>
> [...]
>
> I dunno, I sometimes have stable tagged versions of software checked out
^^^^^^^^^
> and then want to update just one file that I know has had some important
> bug fix made to it. Am I misunderstanding or doesn't that need mixed-revs?
This is definitely a use case. But how often do you really do this?
And what if this particular file has not only this particular bugfix
but also some other changes? Why not _merge_ the bugfix onto the tagged
version? You would need to merge anyway, when there are a lot of
unrelated changes before the bugfix. What do you do with the WC after
having this mixed state? Do you really go ahead and start to
commit/merge/whatever? Or is this mixed state only temporary
and you delete it after you are done with it?
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Julian Fitzell <ju...@beta4.com>.
Josef Wolf wrote:
[...]
> There is no technical reason for the current behavior of cvs/svn, it
> is a _political_ decision.
>
> Maybe you could try again and give me a _real_ use case for mixed-revs?
> Please do not mis-understand me: I _know_ there are real use cases for
> mixed-revs. But I don't believe that those use-cases are so frequent
> that it is worth to burden the day-by-day use.
[...]
I dunno, I sometimes have stable tagged versions of software checked out
and then want to update just one file that I know has had some important
bug fix made to it. Am I misunderstanding or doesn't that need mixed-revs?
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Thu, Aug 01, 2002 at 12:13:42AM +0200, Branko ??ibej wrote:
> >Having used CVS for about 10 years now, I still have no clue why you
> >all want those mixed-revs-stuff. Maybe someone could give me a good
> >use case?
>
> Oh my, that's a good one. CVS has mixed-revision working copies, too.
So your main argument is "We need mixed-revs because we always had
them"?
> When you "cvs commit", only your changes get sent to the server; your
> sandbox isn't updated to HEAD.
>
> As to use cases: When I say "svn ci", I don't want my working copy
> changed. If I want that, I say "svn up". It's as simple as that.
I don't agree with this one. Not modifying your working files on commit
is not related to mixed revs-stuff. When you already are at HEAD,
there is no reason to modify your working files, because they _already_
are up-to-date. Only the administrative area in the .svn directory
needs to be modified. When you are not at HEAD, the commit should
simply fail.
The use case you mentioned above arises only because you already
_have_ mixed revisions at the time of commit. In other words: the
current behavior on commit is needed because you were using mixed-revs
_before_ the commit. It is a _consequense_ of mixed-revs, but _not_ the
_reason_ to introduce mixed-revs in the first place.
There is no technical reason for the current behavior of cvs/svn, it
is a _political_ decision.
Maybe you could try again and give me a _real_ use case for mixed-revs?
Please do not mis-understand me: I _know_ there are real use cases for
mixed-revs. But I don't believe that those use-cases are so frequent
that it is worth to burden the day-by-day use.
But anyway, we already discussed this topic about two months ago and
agreed on leaving it as is for now and discuss it again after 1.0 is
out.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Branko Čibej <br...@xbc.nu>.
Josef Wolf wrote:
>Having used CVS for about 10 years now, I still have no clue why you
>all want those mixed-revs-stuff. Maybe someone could give me a good
>use case?
>
>
Oh my, that's a good one. CVS has mixed-revision working copies, too.
When you "cvs commit", only your changes get sent to the server; your
sandbox isn't updated to HEAD.
As to use cases: When I say "svn ci", I don't want my working copy
changed. If I want that, I say "svn up". It's as simple as that.
--
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: Feature request: Keyword $Rev$ with a twist
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jul 31, 2002 at 11:49:09AM -0500, Ben Collins-Sussman wrote:
> I think that we've all agreed that we don't want to put the
> working-rev into our Subversion's *own* svn_version.h header. But I
> don't think anyone is particularly against the creation of a
> $WorkingRev$ keyword.
>
> We don't want to use this technique in our own header because it might
> lead to a lot of confusion: first, as you say, there's the
> possibility of a mixed-rev working copy. But then also, what if
> somebody checks out the latest fs-convert-2092 branch from HEAD?
> Well, then you'll have a "2092 branch binary" that claims to be at
> revision 2805 or something... big confusion.
Having used CVS for about 10 years now, I still have no clue why you
all want those mixed-revs-stuff. Maybe someone could give me a good
use case?
(WARNING: the rest of this posting is heavy politics. I don't expect
anyone to agree with those sayings)
Anyway, I think all this heavily depends on the politics you want to
run on your project. Just for example: I run the policy to never
release versions which are not tagged. When you agree on such a policy
for your project, then HeadURL contains everything you need. This has
also the advantage that you are not limited to the (internal,
auto-generated) svn revision but can get version strings like V0.14.0
just by doing:
$vers = $HeadURL$;
($version) = $vers=~m!http://svn.collab.net/repos/svn/tags/([^/]+)!;
print qq!# define VERSION "V$version"\n!;
then you could put into your makefile:
version.h: version.pl
perl perlsion.pl >version.h
I have not tried this yet, but this shows the idea I am planning to
setup my projects. Of course there are some issues when the URL is
changed for some reason. But for now I dont want to go too much into
implementation details, just show the general idea.
> But hey, if others want to use a $WorkingRev$ keyword for whatever
> reason, then I'm +0 on adding that feature.
I would prefer some variant of HeadURL where the URL-Prefix is
stripped off so that the perl-match mentioned above would be less
prone to changes in the repository location. But I am not really
convinced that such a keyword is really needed, because you could
minimize those problems with:
($version) = $vers=~m!/svn/tags/([^/]+)!;
You could even extend this to something like this:
$vers = $HeadURL$;
if ($vers=~m!/trunk/!) {
print "WARNING: you are using an inofficial snapshot!\n";
} elsif ($vers=~m!/branches/([^/]+)!) {
print "WARNING: Do you really want to be on HEAD of $1?\n";
} elsif ($vers=~m!/tags/([^/]+)!) {
print "You use version $1, that's OK!\n";
}
Just my Eur 0.02 ;-)
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Feature request: Keyword $Rev$ with a twist
Posted by Mats Nilsson <ma...@xware.se>.
sussman@collab.net [mailto:sussman@collab.net] writes:
> But then also, what if
> somebody checks out the latest fs-convert-2092 branch from HEAD?
> Well, then you'll have a "2092 branch binary" that claims to be at
> revision 2805 or something... big confusion.
It wouldn't be used alone, of course.
I think the following is pretty clear.
$WorkingRev: 2805 $
$URL: http://svn.collab.net/branches/fs-convert-2092 $
That part of the issue is more related to giving branches meaningful names.
In this case fs-convert-2092 means something for those involved.
> But hey, if others want to use a $WorkingRev$ keyword for whatever
> reason, then I'm +0 on adding that feature.
I'd like to have it, but there may be other useful variants. Dave Cridland
was on to something when he spoke about the containing directory's Last
Change Revision. Maybe this can be captured as a keyword?
$ContainingDirectoryLastChangeRev: 2805 $
or rather
$RelativePathLastChangeRev ../..: 2805 $
Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Ben Collins-Sussman <su...@collab.net>.
William Uther <wi...@cs.cmu.edu> writes:
> If I remember correctly, this has come up before. The issue is svn supports
> mixed revision working copies (again, IIRC). You cannot guarantee that the
> value in any file is up to date for any other file in the working copy. If
> you add this keyword in the file revision.h, and then 'svn up' a dir that
> doesn't contain revision.h, then revision.h will not be updated and will be
> contain incorrect information.
I think that we've all agreed that we don't want to put the
working-rev into our Subversion's *own* svn_version.h header. But I
don't think anyone is particularly against the creation of a
$WorkingRev$ keyword.
We don't want to use this technique in our own header because it might
lead to a lot of confusion: first, as you say, there's the
possibility of a mixed-rev working copy. But then also, what if
somebody checks out the latest fs-convert-2092 branch from HEAD?
Well, then you'll have a "2092 branch binary" that claims to be at
revision 2805 or something... big confusion.
But hey, if others want to use a $WorkingRev$ keyword for whatever
reason, then I'm +0 on adding that feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by William Uther <wi...@cs.cmu.edu>.
On 31/7/02 11:44 AM, "Mats Nilsson" <ma...@xware.se> wrote:
>
>
> Dave Cridland [mailto:dave@cridland.net] writes:
>> svn info gives you the last changed revision, as well as the current
>> revision, for any node.
>>
>> AFAICT, for a directory, the last changed revision is when anything
>> inside it changed. I use these as build-revisions, and it seems to work
>> very nicely.
>
> Yes - but that still requires the build process to interact with the source
> code control tools. One more step to perform. I'd like very much to be able
> to separate these actions.
>
> I'd hate if it required me to write something like this in each Makefile:
>
> version.h:
> svn info . | grep Revision | awk '{ print "#define REVISION" $2 }' >
> version.h
>
> Not to mention all the troubles to remember to keep version.h updated after
> each 'svn up' (rm version.h; make version.h).
> And not to mention the troubles of doing this portably (MSVC vs. Makefile
> etc.)
>
> I'd like to do a simple 'svn up' and be done with it.
If I remember correctly, this has come up before. The issue is svn supports
mixed revision working copies (again, IIRC). You cannot guarantee that the
value in any file is up to date for any other file in the working copy. If
you add this keyword in the file revision.h, and then 'svn up' a dir that
doesn't contain revision.h, then revision.h will not be updated and will be
contain incorrect information.
I have no strong feelings either way. I just wanted to point out that this
has been discussed before. You might want to look in the archives for more
info.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Feature request: Keyword $Rev$ with a twist
Posted by Mats Nilsson <ma...@xware.se>.
Dave Cridland [mailto:dave@cridland.net] writes:
> svn info gives you the last changed revision, as well as the current
> revision, for any node.
>
> AFAICT, for a directory, the last changed revision is when anything
> inside it changed. I use these as build-revisions, and it seems to work
> very nicely.
Yes - but that still requires the build process to interact with the source
code control tools. One more step to perform. I'd like very much to be able
to separate these actions.
I'd hate if it required me to write something like this in each Makefile:
version.h:
svn info . | grep Revision | awk '{ print "#define REVISION" $2 }' >
version.h
Not to mention all the troubles to remember to keep version.h updated after
each 'svn up' (rm version.h; make version.h).
And not to mention the troubles of doing this portably (MSVC vs. Makefile
etc.)
I'd like to do a simple 'svn up' and be done with it.
Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: Keyword $Rev$ with a twist
Posted by Dave Cridland <da...@cridland.net>.
On Wed, 2002-07-31 at 14:03, Mats Nilsson wrote:
> Hi
>
> $Rev$ expands to the revision in which the file last changed.
>
> I'm requesting another keyword that expands to the *currently checked out
> revision* for that file. That way it will be easier to get the
> build-revision into the resulting binaries, without having to resort to
> change a file every time.
>
> I guess I could extract that info from the 'svn co' output - but that would
> IMO be less satisfactory, since it would require me to make 'svn co' part of
> the build procedure.
svn info gives you the last changed revision, as well as the current
revision, for any node.
AFAICT, for a directory, the last changed revision is when anything
inside it changed. I use these as build-revisions, and it seems to work
very nicely.
Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org