Ph. Marek wrote:
>> * you never asked whether those properties are final or open for use
> Yes, because ...
>> * after you created the branch and your initial work, you didn't follow
>> through with trying to backport your branch to trunk
> ... the branch wasn't wanted for mainline.
> There's been so much discussion ... see the summary at
Since you couldn't get the others to include your branch, you decided to
take matters into your own hands and just use their properties.
>> Just because you didn't have problems until now, doesn't mean you
>> won't get into troubles in the future. The development is in
> Yes, maybe there'll be another subversion project using "tsvn" as
> short name,
> which would collide with your properties. What will you do about that?
I would beat them with a stick. Seriously: there is something called
'manners', which means before you do something, you first think whether
your plan affects others. And TSVN is clearly a highly visible project,
and 'tsvn' too is well known in the Subversion community. If someone
else would suddenly start using such properties I would publicly call
them some very bad names I don't like to mention here now.
And it's not the same with 'svn' and the 'svn:' properties. Because
'svn' as well as Subversion is trademarked and the trademark belongs to
the Subversion organization. Using those without asking can get you into
>>> Why does svn:log use UTF-8 and not some "internal" encoding? Because it's
>>> already here, and works! Same for these properties: *now* they're matter of
>> Read the docs: the svn:log property is documented and the docs clearly
>> state that the encoding must be utf-8.
> Yes, but *why* was UTF8 chosen? They could've used UCS-16, ASCII, EBCDIC or
> something else. "It works"!
Why do you even care why utf8 was chosen?
The Subversion library provides an API. That API is well documented. The
Subversion developers decide how the API looks and how clients must use
it. If they decide that they want to store information in utf8, then
that's their decision, not yours.
>> If you would use Windows and write apps for it, I'm
>> sure your apps would break a lot of other apps - you don't care whether
>> you're using undocumented functions of any other apps.
> Yes, you're right - I'm known to do things the "working" way rather than going
> the (sometimes too) slow "certification routes".
> Did you never use a hex-editor on some 3rd party programs?
I do all the time.
> Of course, that might mean that it'll break with the next service pack - but
> better it works *now* (and for at least a few years until some change happens)
> than never (because there's just no fix, and possible *no interest*) from the
But even though you must realize that every user of your application
will blame Microsoft (or other poor people who have nothing to do with
your buggy app)? People will install a Servicepack, your app stops
working (because of your fault), but they will blame Microsoft for it -
after all, it worked before the SP installation, so the SP must be broken.
People with your attitude are the reason that many people are angry at
MS or other companies which have nothing to do with their problems - and
you just smile and get away with your crappy applications.
I wish you that you one day have to write a library and then support
that library for a few years and be forced to keep your library
compatible with all older versions. Maybe then you will understand why
people with your kind of attitude should be prevented from ever writing
I'm not saying your bad at coding. I'm just saying your attitude has to
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-09-05 19:47:32 CEST