[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: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 04 Sep 2008 13:24:58 +0200

Ph. Marek wrote:
> Hello Stefan!
> Stefan Küng <tortoisesvn <at> gmail.com> writes:
>> Ph. Marek wrote:
>>> Well, these properties *do* come from (a branch) of the subversion
>>> libraries: the meta-data-branch. They were *designed* for use in
>>> subversion - the feature is just not accepted yet (and might never be
>>> - that's why FSVS was written).
>> So you're saying that now that FSVS has decided to implement something,
>> the Subversion developers have to kindly ask *them* whether they are
>> allowed to use the svn: properties they want for their feature?
> No.
> When I wrote the meta-data branches back in 2003 everybody was busy getting 1.0
> finished; so I got no answer to my proposals, and just chose the names.
>> Or if they want to use it, they have to do *exactly* the same as FSVS does?
> No. Do you have any specific criticism with the names or the format?
> But compatibility is always a valid reason - and there's "svntar" using the
> meta-data-branch names and format, too.

So there are more than just one project using those properties. Great.
Just think about it: if Subversion wants to implement some ACL handling
and wants to use e.g. svn:group for it it's just bad luck: they can't
use their very own property namespace anymore because other apps are
already using those properties without asking.

> asvn (in subversion's contrib/ folder) uses names "file:permissions",
> "dir:devices" and "dir:symlinks" - which is even worse (regarding the
> properties namespace) - and it came later: the first commit in the subversion
> repository is from June 2004, whereas the first patches for meta-data
> versioning were already published 2003
> (http://svn.haxx.se/dev/archive-2003-05/1360.shtml)
> See also bug 1256 (http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
> for a timeline.

Sure, that kind of namespace (actually, it's not a real namespace asvn
uses here) is even worse. But at least it doesn't interfere with
Subversion development.

>> Sorry, that's not a reason. The 'svn:' properties are for the Subversion
>> project *only*.
> Yes, and these properties *come* from there.

But not from an official release. That means those properties are still
'internal' to svn and must not be used.
If you start using any new property that gets introduced on an
experimental branch, you prevent Subversion from ever finishing (or
rewriting) that branch without breaking your app.

>>> That's why the "svn:" prefix is used in FSVS too - to be compatible
>>> with the meta-data branches of subversion!
>> You can't be compatible to something that's not finalized.
> I'd like to skip the discussion of "de facto" vs. "de jure" here.
> I thought that avoiding such discussions are a major plus for OSS.

OSS never avoids discussions - you just failed to discuss this with the
Subversion devs before starting fsvs...

>> I don't care about those: it's on a branch, not yet released. That means
>> it's subject to change.
> Why should it change? Is there some problem with the storage format?
> Do you have any specific ideas how to do that better?

I haven't checked your format. But fsvs is Linux only. Subversion
however works on many platforms with different ACL mechanisms. That
means I would bet good money on it that your format can't handle e.g.
Windows at all. If Subversion would try to do it right, supporting
different platforms, it now can't use their own properties anymore
because you are using them.

Or: they could simply ignore your project and let you deal with your
angry users once your app breaks as soon as they update Subversion.

> If I understand you correctly, if I send a patch to subversion-dev which
> clearly documents the names and formats, and this gets accepted, it would be ok
> for you?

Then those would be officially documented, yes.

>> You don't get it. I don't care whether other tools misuse the svn:
>> properties too. If they do, that's their problem and I hope they will
>> get serious problems one day for doing so.
>> Why do you think TSVN introduced the tsvn: and bugtraq: properties? We
>> also could have used 'svn:' properties instead to 'encourage' other
>> clients to use the same ones. We didn't. Because it is not allowed. And
>> we follow the rules.
> I did, too. I posted a patch, and got a branch and commit rights for that.
> TBH, that sounds a bit like "And *WE* follow the rules", which I restate (in my
> mind) as "You didn't". It may be just me, but I don't think I did something
> wrong; for svn the prefix was clearly ok, and in FSVS I just used the already
> defined (and used!) names.

For svn the prefix was ok because it is the internal svn prefix.
For FSVS to use the svn prefix is *not* ok if Subversion has not
officially documented them or provides an API for it.
Just because those properties are used on a branch (an experimental one
at that) doesn't mean you're allowed to use them! Because as long as the
branch exists, it can still change completely or even get rewritten,
which means the meaning and definition of those properties could change.
With you using those properties, that's not possible without breaking
either Subversion or your app.


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

Received on 2008-09-04 13:25:15 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.