Dear Mr. Rosenfield,
After reading this thread with mild amusement, I feel I have to add
just a little bit. Just my .02 cents.
On 05/09/07, rosenfield@users.sourceforge.net
<rosenfield@users.sourceforge.net> wrote:
> Ansgar Becker wrote:
> > The build_super.cmd needs to check the revision of
> > the working copy and then set it in the sources.
>
> Yeah, the current state of using $Revision kind of sucks.
> It doesn't get updated to reflect the WC state after
> an 'svn update' unless main.pas is modified, which has
> left us with executables containing corrupted version
> numbers on the website :-/.
But the $Revision is exactly relevant when looking at file-scope.
After an update it will have the latest revision that modified that
particular file.
Use a tool like SubWCRev to generate an include file based on another
template file. The generated file is not versioned but only made part
of your project definition & included by the source files that need
it; the template file IS versioned.
>
> > This can be done by using SubWcRev.exe from TortoiseSVN\bin
> > directory. SubWcRev.exe will read
> > \source\const_template.inc and save its parsed result into
> > \source\const.inc so that this file contains the final
> > revision number. The command line is as follows:
> >
> > %ProgramFiles%\TortoiseSVN\bin\SubWCRev.exe ..\..\
> > ..\..\source\const_template.inc ..\..\source\const.inc -f
>
> Whoever wrote SubWCRev really need to fix it so that it will
> just replace the revision number in existing files instead of
> requiring a pair of old+new files.
>
> I can fix SubWCRev if you want, but please don't break stuff
> just to satisfy the requirements of a poorly designed tool.
Don't complain about a hammer not being usable as a screwdriver. There
are valid reasons and use cases for using the tool as it is right now.
And there are serious concerns when trying to stick to the 'single
file that gets updated' approach. Not being able to version that file
being one of them (or not being able to switch from one versioning
system to another IF you get it working for one).
> Even if you do as stated above, you're going to have a file which
> is included for compilation in the project, but which doesn't exist
> before after the build phase. The IDE's default behaviour is to
> remove this file from the project (after asking for confirmation from
> the user) if it's touched. Crap, crap, crap.
Not true, you are perfectly able to start with a dummy generated file
to start with. No need to remove that file (usually it is excluded
from 'make clean' scripts and the like)
>
> You're also going to have a file which, when modified, will silently
> be overwritten with another version when the project is built.
> Mega crap.
Why is that crap? You will always silently overwrite generated files
when projects are build. Developers need to be aware that it is silly
to modify generated files.
I am using DevC++ as IDE and it is perfectly capable of calling
SubWCRev during the compile/builds. It happily includes my generated
version.h to display the latest revision information in the
application.
--
Regards,
Jean-Marc
----------------
___
// \\ @@ "De Chelonian Mobile"
/ \_/ \/._) TortoiseSVN
<\_/_\_/ / The coolest Interface to (Sub)Version Control
/_/ \_\ Check out http://tortoisesvn.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Sep 6 11:19:29 2007