Re: D10 + Pre-Build hook

On 9/5/07, rosenfield@users.sourceforge.net
<rosenfield@users.sourceforge.net> wrote:
> Stefan Küng wrote:
> > > 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.
>
> It would not, surely. Of course, Subversion needs to be told
> that it's a keyword and that it should ignore it. This already
> happens for $Revision along with a myriad of other keywords,
> so it's hard to imagine that this simply would not work for one
> particular new keyword.
>
> (Even _if_ it was that inflexible, there's always the option of
> piggy-backing on an existing keyword, fx $Revision.)

Well, the 'Subversion needs to be told that it's a keyword' is not
possible without hacking Subversion itself. So that's out of the
question (for now).
Piggy-backing on an existing keyword is an even worse idea (try and
you'll discover why), because one would overwrite the other.

> > > 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'.
>
> Apologies, did not intend to hurt anyone's feelings. I just meant
> that it's a broken design when used in combination with an IDE.

Or maybe the IDE is broken? :)
Seriously: you really should use template files for this. And use some
kind of build script (or a pre-build step in your IDE) to generate the
real file from the template. If you do that, you can avoid all
problems which you would have otherwise.

And if you read the docs of SubWCRev (or just type SubWCRev without
any params at the console) you could discover that you simply could
specify the same path as the source and as the destination file. That
way SubWCRev would replace the tags in the source file.
The problem then would be: the tags are gone, and it wouldn't work a
second time.

Without replacing the tags (i.e., doing something similar as the svn
keywords) SubWCRev would simply be a bad keyword replacement. But it
isn't. It was designed to be used for situations where information
about a working copy is needed in other than comments in a file. For
example, a define, a string, ...
Keywords don't work very well when used in strings or defines - you
either have to accept that the string/define contains the keyword too,
or somehow programmatically remove it before using it.

> > > 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...
>
> Thanks. I take it that you don't want to see patches ;-).

Well, if you have something that would improve SubWCRev, then patches
are always welcome. But it seems to me that you haven't really thought
this through yet? Or SubWCRev is simply not what you need but
something completely different (which only seems to be related because
of the 'revision number' thing, but serves a different purpose).

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