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

Ph. Marek wrote:
> Stefan Küng <tortoisesvn <at> gmail.com> writes:
>> Ph. Marek wrote:
> ...
>>> 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.
>> The svn:log property is documented as an *internal* property for
>> Subversion, not to be used directly by other applications. The only way
>> to use those is via the Subversion API.
>> Those who think they can do whatever they want with internal data (like
>> you) will lead to them having broken applications.
>>
>> Don't blame others for not being nice if you're not even willing to
>> follow their rules.
> You're missing the point. Rather than "just" inventing a new name for the
> properties (and breaking all existing repositories for all users) I used the
> (already registered) name and meaning.

So you used the property as it was documented. That's ok. You can use
anything that's documented in the way that it is documented.
That's what I'm talking about here. Only if you start using internal
data which is not documented or not the way it is documented, *that's* bad.

> It's about the users, and compatibility with their data.
>
> That's what I meant about using UTF8 - that's an existing standard, which
> (most) editors know how to handle.
>
> If you invent new names for existing things (like I meant for "open"
> vs. "GetHandleForAFile"), you'll cause people trying to use your OS more work -
> because they have to get some compatibility layer for their programs, or change
> *every one* of them.
>
> And once again - IMO I followed the rules. Something developed for subversion
> used the namespace "svn:" (naturally!); that it wasn't accepted is not my
> fault.

But since it wasn't accepted, it wasn't documented and the svn:
properties were not for use by other apps.

For example, you use the property svn:groups - 'groups' can be used for
many things like a group of users, a group of commits, a group of
repositories, ...

> But I had to take care for the existing users.

What existing users? That many people were using that experimental
branch of yours can't be counted as 'existing users'.

>>>>> 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?
>> Can you explain why using a HEX-Editor is 'not the right way'? You have
>> no idea what I'm using those for.
>> I guess for you the only way to use a hex-editor is to hack another
>> application...
> Yes, it is.
>
> If I've got the source, I can re-compile.
> If I don't have the source, but the vendor is listening, I can get a changed
> binary.
>
> So you're right - I use a hex-editor for hacking.
>
> But you didn't answer the question - why do *you* use it, if the proper way is
> to get everything the official, planned, documented way?

I use hex editors for many things. For example, I create test files for
TortoiseMerge with it - it's much easier to create a file which has all
kinds of EOL styles in it with a hex editor by changing an existing text
file.

As you've probably noticed, TSVN uses a lot of custom properties (tsvn:
bugtraq:, webviewer:, ...). When I first started implementing the
features which required properties, I ask on the svn mailing list
whether I could use svn: properties for those, since I wanted not just
TSVN to have those features but other svn clients as well, and having
those properties documented in the svn project would help.
But that proposal wasn't accepted (I could say now that this wasn't my
fault either).
But instead of just using svn: properties anyway, I used other
properties. That's the right way to do things.
Do I think that this is the best way? No, certainly not. I'd rather have
official svn properties for most of the features, and I guess Subclipse
would also prefer svn properties (but they now also use the tsvn:
properties). But still: it is the right way. I don't mess with other
projects.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net