[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request: Vizualization of 'fsvs' properties.

From: Ph. Marek <philipp_at_marek.priv.at>
Date: Sat, 6 Sep 2008 10:16:05 +0000 (UTC)

Stefan Küng <tortoisesvn <at> gmail.com> writes:
> I see.
> 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.
> Nice.
A)

> >>> 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 fact.
> >> 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?
and B): because of *compatibility*. If you wrote a new OS, would you call the
function that's used to open files "open", or would you name
it "GetHandleForAFile"?

There've been *existing users* for these properties. Changing them would have
broken their data.

That's* not nice.
 
> >> 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.
So you do? Why? Because if I read you correctly that's not the right way, is
it? Why do you do this? For your private use?

> > 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 vendor).
>
> 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)?
No, they won't, because 1) that's only for use in controlled environments, and
2) it's clearly documented, where the relevant people find the information.

> 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.
No, they won't either - because the SP installation would be prepared *by me*,
so I know what to look for, and change it *again* (since it wouldn't be fixed
in SP3, after I complained for SP1).

> 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.
Thank you. Is that good manners?
You're trying to press me into a slot of your liking, for easier bashing; see
here: http://www.paulgraham.com/disagree.html.

> 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.
I did, and had to do some changes because of 3rd party libraries changing.
I know what this kind of works means.

> Maybe then you will understand why
> people with your kind of attitude should be prevented from ever writing
> applications.
No, I don't.
 
> I'm not saying your bad at coding.
Thank you, that's the first nice thing you write.

> I'm just saying your attitude has to change.
To be honest, I wouldn't know where to start.

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-09-06 12:37:12 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.