rosenfield@users.sourceforge.net wrote:
> 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?
So you're saying you would rather patch Subversion than to *slightly*
adjust your build process?
> 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.
There's an issue for this in the Subversion issue tracker. Feel free to
add your comments there.
> (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..)
If you had a user who really added file by file to the repository, then
that's not a deficiency in TSVN but in your whole process. You simply
have to train new people, at least tell them the *basics*.
>> 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 :-).
I'm sorry, but you are the one who knocked down the door here yelling
about 'broken tools' and 'crap', and that you could do it much much
better. Usually, before you do that you should have thought about your
much better tool a little bit more. It's not as if you missed some
really hidden and rare condition which makes your approach not work but
something (I'd say) very basic.
>>> 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 ;-).
I'm almost sure that such a change won't get accepted in Subversion.
Always think first "what if others want to do the same?". Think about
it: 100 people want to have their own, special keywords...
FYI: there's already an issue open in the Subversion issue tracker
"custom keywords". Maybe that's what you could use?
http://subversion.tigris.org/issues/show_bug.cgi?id=890
> We sort of intend to have this stuff in place at the end of the month
> rather than next year, if at all possible.
Changing the svn library and having the change accepted in one month? I
don't think that's possible...
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 Thu Sep 6 17:48:30 2007