On 9/5/07, rosenfield@users.sourceforge.net
<rosenfield@users.sourceforge.net> wrote:
> Ansgar Becker wrote:
> 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 :-/.
The alternative would be worse.
> > 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.
It doesn't need to be fixed. It's not SubWCRev that's broken but your
understanding of version control.
If it would modify an existing file under version control, that file
would always show up as modified and get committed every time. That's
not good, and not wanted.
> I can fix SubWCRev if you want, but please don't break stuff
> just to satisfy the requirements of a poorly designed tool.
Sorry, you can't fix what's not broken.
And please think first before you call something 'poorly designed'.
> SubWCRev seems designed for unix makefiles where a temporary file can
> be created just for the purpose of compiling and then removed again
> afterwards. It's just plain crap when used together with a good IDE.
SubWCRev only runs on windows. Does that give you a hint?
And again, *think* before calling SubWCRev crap.
(I could do the same with your "good" IDE).
> Rightly so IMHO.
> Let's just fix SubWCRev so it works with strings, just as $Revision.
I wonder if I should just tell you to modify SubWCRev to your needs?
Would be funny to watch you deal with all the broken working copies,
broken builds, ...
> We can't make it run automatically on 'svn update' and 'svn commit'
> unfortunately, so we'll still have to put it in the pre-build
> commands for various IDE versions and the build .cmd. I guess
> that's OK, we need to have something there anyway in order to
> get the "has local modifications?" flag correctly into the source
> code and the final executable.
If you want a clean, *working* solution, then do what TSVN does (and
all other projects which like something that works): use a template
file which gets 'copied' by SubWCRev to a file that is then included
in your project.
Usually, you will need such template files for all the stuff which
needs local/absolute paths anyway.
> I'll take a look at fixing SubWCRev. I think it's GPL, so we can
> include the modified version in our repository under 'extra'.
Once again, you can't fix what's not broken. Good luck trying though...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Sep 5 13:30:52 2007