[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: Fri, 5 Sep 2008 17:19:10 +0000 (UTC)

Stefan Küng <tortoisesvn <at> gmail.com> writes:
> Ph. Marek wrote:
> >> OSS never avoids discussions - you just failed to discuss this with the
> >> Subversion devs before starting fsvs...
> > Sorry, Stefan. That's where I accuse you of not reading the pointers I sent
> > you.
> > On 2003-05-16 (http://svn.haxx.se/dev/archive-2003-05/1360.shtml) I sent a
> > first patch using svn:text-time (using that on commit only) - and
> > when starting
> > FSVS some years later (May 2005, to be exact) I haven't heard any specific
> > feedback regarding the names or formats I used.
> I've read that. But you just don't get it (sorry, but it's true):
> * 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

> * you started your own project, using those properties without asking.
> Even though you introduced them, you can't use them for your projects:
> those properties belong to Subversion.
Yes, they do.
They are just used by FSVS too, because they're *identical* by name and
definition with the things used in the meta-data branch.

> I mentinoned this before: what if Subversion wants to use the very same
> properties in the future? From their point of view, they can use those
> properties for whatever they see fit. You can't expect them to search
> the whole internet for projects which might already use those properties
> differently and then either use different ones (which then had to be
> some awkward names because you already used the correct ones for that
> feature) or ignore you and break your tool.
> An existing branch in the Subversion repository does not mean that what
> is in that branch is free to use - it happens a *lot* that a branch is
> removed, and later the feature for which the branch was created in the
> first place is then implemented a different way. And since the svn:
> properties are for Subversion, they can use those if they want.
> > And now the situation is that there are patches and branches for subversion
> > using that for more than 5 years - and I have heard *no single*
> > problem with the 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 progress.
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?

> > As the subversion project didn't give any feedback (about these
> > properties), it's too late now - they're in use.
> That's exactly the problem. You used those without asking - no feedback
> does not mean you got the permission to use them.
"Qui tacet, consentire videtur." - as you surely know.

> > I cannot make myself clear, I think.
> >
> > For *five* full years I've heard *no* comment about the properties.
> > If the subversion project should choose to define new properties, I
> > sure hope that they don't just take these.
> You own a piece of land, somewhere in the country. But you live in a
> city and don't use your land right now. Someone else is using it without
> you knowing for five years. You never hear anything about that.
> Then one day you decide to build a house on your land - sorry, someone
> else is using it and you haven't objected for five years - go back to
> your apartment in the city.
> Can you see how flawed your argument is?
No. For non-material things like patents there's much discussion whether unused
(or un-implemented) patents should just get invalid after a few years, and your
comparision is invalid in another point: there's just some more land, a single
bit away.

 [Yes, right - just a single bit: subversion is case-sensitive in property
    $ LANG=C svn pl -v aa
    Properties on 'aa':
      X : X1
      x : x2
 And a "svn:Group" is equally readable, isn't it? ]

> > 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"!

> > Stefan, thank you for your answers.
> > But IMHO your points are on lost ground; I'll stop discussing here.
> > Maybe I'll try to get the properties "official".
> > Maybe your users can get some vote that they'd like visualization of these
> > properties in the repository browser.
> >
> > I don't use Windows; I don't really mind.
> That's a relief.
That sounds like a insult, but:

> 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?

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

I can just wish you further good luck, if you never had to resort to
such "solutions".

I thought some time whether it's worth answering - we don't seem to get
anywhere. Thank you for your opinion; I understand your point, but I just don't
share it.

Good luck for the future!

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-05 19:20:01 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.