David,
what you're proposing is really easy.
Cut the version info out of your .rc file and put it in your
.rc2 file (which is probably fairly empty.) Then add a ".in"
extension to the rc2, and make the changes that you want for
SubWCRev to work.
Add the file as a source to your Visual Studio project, right
click on it, properties, custom build step, general.
Command line is something like
subwcrev $(SolutionDir)..\..\ $(InputPath) $(InputDir)$(InputName)
Outputs are like:
res\$(InputName)
etc.
Visual Studio will figure out that it needs to "compile" your
input to make the necessary .rc2 file to include in the .rc
file. Make sure that the .rc2.in file is under source
control, and the .rc2 file (which is now a generated product), is not.
You might need to fiddle with the paths, but I've never had a problem.
Good luck.
Peter.
> > -----Original Message-----
> > From: DK [mailto:dk@dsl.pipex.com]
> > Sent: Tuesday, 31 October 2006 10:39 AM
> > To: 'Erik Huelsmann'
> > Cc: users@subversion.tigris.org
> > Subject: RE: Inserting revision numbers in source
> >
> >
> > Erik,
> >
> > Thanks but I had seen that FAQ and either it isn't
> > appropriate or I don't
> > understand how to implement it in MS Visual Studio 2005 ;-(
> >
> > In the example (for a GNU Makefile), it shows how to get the
> > value in a C
> > program. Unfortunately, I need this value hard coded in the
> > resource file
> > (that is why I put the defines as they were since Windows
> > resource files can
> > include C Header files), so that the correct build
> > information is included
> > in the executable (as seen by looking at the version in the
> program's
> > properties using right-click under Windows Explorer).
> >
> > The FAQ also references SubWCRev.exe, just like I did, but
> > that updates the
> > user's working copy which becomes out of step to the version in the
> > repository and requires everyone who updates the repository
> > to do it on
> > their own working copy.
> >
> > Much better is Subversion did it in the repository at every
> > commit time.
> >
> > If a commit can't send something back, I suppose the user
> could do an
> > immediate update following a commit. Can an update be limited
> > to just one
> > file (version.h)? I am not sure I would be allowed to set up a
> > "post-commit" script on a SourceForge.net repository!
> >
> > But then again, maybe I am missing something?
> >
> > David
> >
> >
> > -----Original Message-----
> > From: Erik Huelsmann [mailto:ehuels@gmail.com]
> > Sent: 30 October 2006 23:20
> > To: DK
> > Cc: users@subversion.tigris.org
> > Subject: Re: Inserting revision numbers in source
> >
> > > I would like to know if anyone has asked for this before
> > and, if so,
> > > what the answer/solution was?
> > >
> > > I am a developer on a C++ project hosted on
> SourceForge.net, which
> > > uses Subversion as its repository. I would like the Subversion
> > > repository to mimic the antics of TortoiseSVN's program
> > "SubWCRev.exe"
> > automatically.
> >
> > Yes, even so often someone decided to write a FAQ about it:
> >
> > http://subversion.tigris.org/faq.html#version-value-in-source
> >
> > But, it's also hard to implement (efficiently), given mixed
> > revision working
> > copies:
> >
> > http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.htm
> > l#svn.basic.in
> > -action.mixedrevs
> >
> > > By this I mean that I would have two members in the source
> > > ("version.in" and
> > > "version.h") with "version.in" being (less my comments):
> > >
> > >
> > > #define FILEVER 3, 4, 0, $WCREV$
> > > #define PRODUCTVER 3, 4, 0, $WCREV$
> > > #define STRFILEVER "3, 4, 0, $WCREV$\0"
> > > #define STRPRODUCTVER "3, 4, 0, $WCREV$\0"
> > >
> > > What I would like is that when anyone commits anything to this
> > > project, Subversion copies "version.in" to "version.h"
> > (overwriting it
> > > if it exists) whilst it substitutes the $WCREV$ (or
> > differently named
> > > keyword to be distinct from TortoiseSVN's program) with
> the current
> > > revision number (if "version.in" is changed during the
> > commit, then it
> > > would be copied after the change has been committed).
> > >
> > > During the commit process, the new "version.h" would be
> > sent back to
> > > the user committing his/her change so that their working copy is
> > > identical to that stored in the repository.
> >
> > Well, there's no such thing as 'send back to the user' in a
> > commit process,
> > but it could be done in post-commit. However not without
> > scanning the full
> > source tree, which comes at a (very large) cost (time)...
> >
> > > This way "version.h" always has the current build number in
> > it should
> > > anyone Checkout the project.
> > >
> > > This differs from the current $Rev$ keyword in that the
> > whole field is
> > > replace by a numeric value rather than inserting the
> > revision number
> > > after the "$Rev:" string i.e.:
> > >
> > >
> > > #define FILEVER 3, 4, 0, $Rev$:
> > >
> > > would become
> > >
> > >
> > > #define FILEVER 3, 4, 0, $Rev: nnnn$:
> > >
> > > which is not a valid C statement. This would not be a
> problem for
> > > future updates as the source file ("version.in") was not altered.
> > >
> > > It also differs from the SubWCRev program which would, in
> > the process
> > > of updating "version.h" mark the directory as updated and
> hence now
> > > different from the repository.
> > >
> > > I would envision a different keyword associated with the
> > "version.in"
> > > file in the Subversion repository - something like $Rev$
> > but meaning
> > > replacing the whole keyword string with the revision number and
> > > specifying the name of the file to be replaced (in my case
> > "version.h").
> > >
> > > If anyone has an alternative solution, I would be
> grateful to hear.
> > >
> > > Thanks
> > >
> > > David.
> >
> > Bye,
> >
> > Erik.
> >
> >
> ---------------------------------------------------------------------
> > 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
> >
>
Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 8884 1000 Sydney, Australia.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 31 01:33:37 2006