Peter,
Thanks.
I am already using the .rc2 file (as that is the only way to include your
own C header files - "version.h"). I am doing something very similar to
your proposal except I do it via a C header included in the .rc2 file rather
than using SubWCRev to change the .rc2 file directly. Very similar
approaches.
I have both version.in and version.h under source control. If I took
version.h out of source control then it would solve my problem of SubWCRev
making my working copy look "modified" to SVN but....
can I guarantee that all developers will use the same approach and use the
Custom Build step?
I'll have to think on this some more.
Thanks for your help.
David
-----Original Message-----
From: Peter Dulimov [mailto:PeterDu@resmed.com.au]
Sent: 31 October 2006 00:33
To: users@subversion.tigris.org
Subject: FW: Inserting revision numbers in source
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 31 09:18:33 2006