Stefan Küng wrote:
>> Won't adding a new keyword to 'svn:keywords' do it?
>
> No, sorry.
It will have to be a workaround then. My guess is that it will not be
the first in the history of Subversion-based development?
I consider it a deficiency in Subversion. An unrelated deficiency is
the lack of ability to specify a configuration setting in the
repository which automatically propagates to all TortoiseSVN clients.
(Off-topic:
Administratively disabling the repository modification functions of
the TSVN repo browser would be sweet, for example. We've had a new
user who did a zillion commits like 'add folder', 'submit file 1 of
new code', 'submit another file', 'submit a third file', etc..)
> As I mentioned: I think you have not thought this through yet.
Yes, I noticed (and happily ignored) that comment the last time. It
may be true, but I don't appreciate being told that I'm using neither
side of my brain. I'd enjoy the criticism much more if you could
point to something concrete as being wrong :-).
>>> 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.
>
> It won't. It only ignores the expanded keyword strings of keywords
> it knows. It doesn't know your custom keyword, so the file will
> always show up as modified.
The above (above) was said in the context of "piggy-backing", so it
should work..
>> 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.
>
> If you really want to invent a new keyword, you would have to patch
> the Subversion library.
Probably not a problem code-wise. But... We'd have to get it
distributed to end users, which means I'd have to get it accepted by
the main developers of Subversion, who are in turn unlikely to see the
point of the patch without seeing the concrete benefits it has
brought, which is in turn something that is not going to happen before
they
accept the patch, et cetera. Aside from the time waste on that
excercise, it takes time for the new feature to go into a release for
people to start upgrading, etc. I'm happy to declare the entire
process "broken" before even getting into it ;-).
We sort of intend to have this stuff in place at the end of the month
rather than next year, if at all possible.
(Off-topic:
PS. Nice picture on your gmail account - very gigerish!)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Sep 6 09:20:59 2007