Ph. Marek wrote:
> Molle Bestefich wrote:
> > My english blows, but I'll give it a shot. Please bear with me for a
> > moment. I'm using GoogleMail, if this posting is malformed (lines too long,
> > etc.) please let me know!
> > Skim towards 'Proposal' if you're real lazy.
> >
> >
> > The $Revision$ keyword
> > ========================
> > Say I have a project, 5 source files that compile to 1 executable.
> > I stick the $Revision$ keyword in one source file to get the revision
> > number compiled into the final project.
> >
> > I'm guessing this is the main use case for $Revision$ ?
> >
> > Surprise, it won't work.
> > The $Revision$ number will reflect the last committed revision of the
> > particular file it's in.
> > But I could've easily modified one of the other 4 files and thereby
> > changed the entire project, without this fact reflecting in the final
> > project's compiled-in revision number.
> >
> > Dare I say it, but this seems to render the $Revision$ keyword most
> > unusable.
> >
> >
> > What's needed
> > ================
> > We need a keyword that says something about the project as a whole.
> >
> >
> > The SubWCRev Way
> > ===================
> > SubWCRev finds which file in the current WC (and below) has the newest
> > 'last committed revision' and uses that number instead.
> >
> > It then reads your SVN'ed source files and replaces all $SUBWCREV$
> > keywords in their entirety with the revision number it finds.
> > That differs a bit from the Subversion way of modifying the yyy part
> > of a $xxx: yyy$ string, but that's a minor detail, so forget about
> > that for the time being.
> If you forget about this requirement, your problem below vanishes:
Not a requirement, just the status d'jour :-).
> > The big disappointment with SubWCRev is that it saves the resulting
> > data into a whole new source file, which we'll call the "result file".
> >
> > In fact, it can do little else, since saving into the original source
> > file would be considered a file change by Subversion, which would have
> > to be committed.
> > Committing would bump the revision number of the project even though
> > nothing had actually changed - bad.
> > Also, it would cause another SubWCRev rev bump, leading to another
> > commit, ... there we have an infinite loop.
> A change "$Id: 45$" to "$Id: 56" does not make the file different, as both are
> translated to "$Id$" before commit.
So.. Have I gotten this right:
What you propose is to keep the external SubWCRev tool for doing this
(and keeping the quite useless $Revision$ sort-of-pendant keyword in
svn), but hack SubWCRev to use one of Subversion's keywords, so that
SVN will be tricked into not saving the changes when committing?
I agree it seems it would work, but it's "a bit" hackish, isn't it?
Doesn't seem quite good enough to be the officially recommended way of
doing things, does it?
> > Either way (a or b:c or b:d) seems fine to me, however I lean towards
> > a.) for it's simplicity.
> >
> > There's also the small kink of mixed revisions.
> > The keyword is meant to represent the revision of the working copy as a
> > whole. If that cannot clearly be determined because different parts of the
> > WC has been updated to different revisions, let's just expand the keyword
> > to "mixed" or perhaps "mixed (min:max)".
>
> I'd suggest using in your Makefile
> SOURCEREV := $(shell svnversion .)
> CFLAGS .= -DSOURCEREV=$(SOURCEREV)
> and in some .c file
> printf("Version is ", #SOURCEREV );
> (maybe #SOURCEREV#, I'm not sure).
>
> Or for more complicated cases even
> SOURCEREV := $(shell svn st -v . | gzip | uuencode)
> and rest as above.
Thanks for the suggestion!
However, we don't use Makefiles.
We use VS.Net's build system, in which it is not practical to do
something like the above.
I imagine the same is true for other build systems..
> Better :-) ?
Afraid not, but many thanks for trying.
Changing the topic a wee bit, I wrote:
> c.) Document that keywords are *only* updated when 'svn up/co' is
> executed, and so may be "out of state" if sub-WC-folders are updated.
Option b:c mentioned above is on second thought not acceptable, since
the whole point of integrating the keyword in 'svn co/up' is to make
the rev number(s) in the WC consistent upon commit/update, just like
the other keywords. Options a.) and b:d.) are still fine solutions,
though ;-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 29 15:30:04 2005