On Thursday 29 September 2005 13:22, 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:
> 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.
> 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.
Better :-) ?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 29 13:42:08 2005