Stefan Küng wrote:
> rosenfield@users.sourceforge.net wrote:
> > 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).
Won't adding a new keyword to 'svn:keywords' do it?
> Piggy-backing on an existing keyword is an even worse idea (try
> and you'll discover why), because one would overwrite the other.
No problem, we intend to run the modifier in the pre-build phase and
the build script anyway. The important thing is that Subversion
ignores the expanded keyword string.
There's also the option of just inventing a keyword, not telling
Subversion about it, and removing it's contents again post-build. That
would leave all sorts of issues with broken files when a machine
crashes etc, so that's bad. Piggy-backing seems the thing to do, if
using a proper keyword won't work, as you say.
> > I just meant that it's a broken design when used in combination
> > with an IDE.
>
> Or maybe the IDE is broken? :)
Hmm, IMHO no, it seems a reasonable notion that any particular file
exists only once in the filesystem.
> 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.
I believe (myself) that I've already made clear why this is a bad
solution, so I'll refrain from repeating myself!
> 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.
Exactly - that's what I intend to change.
"Change" is perhaps wrong; I intend to add it as a new option rather,
in order to make the source differ as little as possible from the
"official".
> 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, ...
Makes perfect sense then.
> 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.
Removing it programmatically is fine here, we don't have any
problematic tools or what not that would have problems coping with the
extra string contents. Totally minor issue. (I think there's even a
one-liner in the project code right now which fixes up such a string.)
> > 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).
Maybe. For me, 95% (the hard part) is about getting the right version
numbers. Stuffing them into a file one way or the other is code-wise a
minor issue. I think it fits within the realms of SubWCRev.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Sep 5 15:33:28 2007