Feature request: Vizualization of 'fsvs' properties.
mmm4m5m
http://fsvs.tigris.org/
"It is a complete backup/restore/versioning tool for all files in a
directory
tree or whole filesystems, with a subversionTM repository as the
backend.
You may think of it as some kind of tar or rsync with versioned
storage"
Example how fsvs store meta data (like time, mode, owner, group):
> $ svn proplist -v file://.../backup/fsvs/trunk/etc/adjtime
> svn:text-time : 2008-08-12T13:36:21.000000Z
> svn:unix-mode : 0644
> svn:owner : 0 root
> svn:group : 0 root
There is no one GUI fsvs client.
These properties are less or more official.
Hope there'd "just" be a few columns more in the directory view (if
any
meta-data properties are set),... possibly a diff to the last values
when
looking at a certain revision (of a file or directory, or the log).
Please, take a look:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h?r1=13200&r2=13261&pathrev=18079
http://svn.collab.net/repos/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h
http://svn.haxx.se/dev/archive-2005-09/0392.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-uns...@tortoisesvn.tigris.org
For additional commands, e-mail: dev-...@tortoisesvn.tigris.org
mmm4m5m
... I hope: "wow, how did we miss this nice feature" :)
regards,
Plamen.
mmm4m5m wrote:
> Feature request: Vizualization of 'fsvs' properties.
---------------------------------------------------------------------
Stefan Küng
> Feature request: Vizualization of 'fsvs' properties.
>
> http://fsvs.tigris.org/
> "It is a complete backup/restore/versioning tool for all files in a
> directory
> tree or whole filesystems, with a subversionTM repository as the
> backend.
> You may think of it as some kind of tar or rsync with versioned
> storage"
>
> Example how fsvs store meta data (like time, mode, owner, group):
>> $ svn proplist -v file://.../backup/fsvs/trunk/etc/adjtime
>> svn:text-time : 2008-08-12T13:36:21.000000Z
>> svn:unix-mode : 0644
>> svn:owner : 0 root
>> svn:group : 0 root
And with those properties, the fsvs project violates the Subversion guidelines.
If they want to use properties, they *must not* use svn: properties:
those are reserved for Subversion.
> There is no one GUI fsvs client.
>
> These properties are less or more official.
No, they can't be.
> Hope there'd "just" be a few columns more in the directory view (if
> any
> meta-data properties are set),... possibly a diff to the last values
> when
> looking at a certain revision (of a file or directory, or the log).
>
> Please, take a look:
> http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h?r1=13200&r2=13261&pathrev=18079
> http://svn.collab.net/repos/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h
> http://svn.haxx.se/dev/archive-2005-09/0392.shtml
Sorry, but TortoiseSVN is not a client for fsvs. And it will never be.
If you want an UI to show those properties, that's the job of a
separate client.
And as long as fsvs uses illegal properties, I won't even touch that project.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Ph. Marek
Stefan Küng <tortoisesvn <at> gmail.com> writes:
> On Wed, Aug 20, 2008 at 16:22, mmm4m5m <mmm4m5m <at> gmail.com> wrote:
> > Feature request: Vizualization of 'fsvs' properties.
...
> > Example how fsvs store meta data (like time, mode, owner, group):
> >> $ svn proplist -v file://.../backup/fsvs/trunk/etc/adjtime
> >> svn:text-time : 2008-08-12T13:36:21.000000Z
> >> svn:unix-mode : 0644
> >> svn:owner : 0 root
> >> svn:group : 0 root
>
> And with those properties, the fsvs project violates the Subversion
> guidelines.
> If they want to use properties, they *must not* use svn: properties:
> those are reserved for Subversion.
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).
That's why the "svn:" prefix is used in FSVS too - to be compatible with the
meta-data branches of subversion!
See here for the definition - from line 192 on:
http://svn.collab.net/repos/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h
> > There is no one GUI fsvs client.
> >
> > These properties are less or more official.
> No, they can't be.
What would be needed to make properties "official"? Get some trademark?
Come on, in the official subversion online repository browser you can see this
names reserved - which is much more than can be said by a lot of other
properties that are used by other utilities.
> > Hope there'd "just" be a few columns more in the directory view
...
> Sorry, but TortoiseSVN is not a client for fsvs. And it will never be.
That's right. Not yet :-)
Maybe there'll be client libraries for FSVS that are compatible with the ones
from subversion - then it's just a question which client is installed, isn't
it?
> If you want an UI to show those properties, that's the job of a
> separate client.
Well, TortoiseSVN includes a repository browser - and I know some people
adminitrating UNIX machines from Windows. And for them it would be nice to be
able to *directly* see the owner, group, etc. - at least if they check some box
in the configuration dialogs.
> And as long as fsvs uses illegal properties, I won't even touch that project.
I hope I could convince you that they are not "illegal"; if I didn't manage
that yet, just say so - then I'll to ask some core subversion developer about
his opinion. Would that help?
Regards,
Phil
Stefan Küng
> Hello Stefan!
>
> Stefan Küng <tortoisesvn <at> gmail.com> writes:
>> On Wed, Aug 20, 2008 at 16:22, mmm4m5m <mmm4m5m <at> gmail.com>
>> wrote:
>>> Feature request: Vizualization of 'fsvs' properties.
> ...
>>> Example how fsvs store meta data (like time, mode, owner, group):
>>>
>>>> $ svn proplist -v file://.../backup/fsvs/trunk/etc/adjtime
>>>> svn:text-time : 2008-08-12T13:36:21.000000Z svn:unix-mode :
>>>> 0644 svn:owner : 0 root svn:group : 0 root
>> And with those properties, the fsvs project violates the Subversion
>> guidelines. If they want to use properties, they *must not* use
>> svn: properties: those are reserved for Subversion.
> 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?
Or if they want to use it, they have to do *exactly* the same as FSVS does?
Sorry, that's not a reason. The 'svn:' properties are for the Subversion
project *only*.
>
> 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.
> See here for the definition - from line 192 on:
> http://svn.collab.net/repos/svn/branches/meta-data-versioning/owner-group-mode/subversion/include/svn_props.h
I don't care about those: it's on a branch, not yet released. That means
it's subject to change.
>>> There is no one GUI fsvs client.
>>>
>>> These properties are less or more official.
>> No, they can't be.
> What would be needed to make properties "official"? Get some
> trademark? Come on, in the official subversion online repository
> browser you can see this names reserved - which is much more than can
> be said by a lot of other properties that are used by other
> utilities.
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.
No, you don't need a trademark. To make these official, you'd have to
contact the Subversion devs and ask them to mark those properties as
final and documented in a release tag, not just in a design document on
an experimental branch.
> I hope I could convince you that they are not "illegal"; if I didn't
> manage that yet, just say so - then I'll to ask some core subversion
> developer about his opinion. Would that help?
It would help, yes. (btw: I'm a full committer on the Subversion project
too - and you couldn't convince me :)
Ph. Marek
> > 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?
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.
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.
> Sorry, that's not a reason. The 'svn:' properties are for the Subversion
> project *only*.
Yes, and these properties *come* from there.
> > 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.
(Linux or *BSD introduce a new system calls, and if it's useful it gets added
to SuS - that seems to work.)
> 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?
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?
> 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.
> No, you don't need a trademark. To make these official, you'd have to
> contact the Subversion devs and ask them to mark those properties as
> final and documented in a release tag, not just in a design document on
> an experimental branch.
Ok.
> > I hope I could convince you that they are not "illegal"; if I didn't
> > manage that yet, just say so - then I'll to ask some core subversion
> > developer about his opinion. Would that help?
>
> It would help, yes. (btw: I'm a full committer on the Subversion project
> too
Yes, I know.
> - and you couldn't convince me :)
Seems so :-)
Maybe I'll try to get that names and formats official; whether TortoiseSVN
allows easier browsing of these properties makes no big difference for me.
But your users might like it ;-)
Stefan Küng
> 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.
Ph. Marek
> 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.
> 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.
> 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.
> OSS never avoids discussions - you just failed to discuss this with the
> Subversion devs before starting fsvs...
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.
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.
As the subversion project didn't give any feedback (about these properties),
it's too late now - they're in use.
> I haven't checked your format. But fsvs is Linux only. Subversion
> however works on many platforms with different ACL mechanisms.
Yes, by ignoring them.
> 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.
There's *no* easy way that Windows' ACLs and Unix permissions can be matched.
Look at the mess the cygwin project has.
> 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.
Ok, so at least that's common ground.
> 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.
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.
> which means the meaning and definition of those properties could change.
So the used names have to keep that meaning. No problem, there's a lot of space
for other names.
And the definition doesn't seem to be a problem. It's just *a* definition, and
that should be sufficient - until someone proves otherwise.
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.
So the best way is to get them officially documented, and there'll never be a
problem.
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.
Thank you again, and good luck with TortoiseSVN (honestly! Not meant sarcastic,
or something like that).
Stefan Küng
>> 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
* after you created the branch and your initial work, you didn't follow
through with trying to backport your branch to trunk
* 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.
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.
> 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.
>> 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.
> There's *no* easy way that Windows' ACLs and Unix permissions can be matched.
> Look at the mess the cygwin project has.
cygwin itself is a mess (my opinion).
And just because there is no easy way doesn't mean the Subversion devs
won't ever try.
> 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?
> 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.
> 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. 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.
mmm4m5m
From my point of view, the problem is slightly different. Let me try
to explain:
if programmers use svn to version source files, administrators could
use fsvs to commit configuration files.
You could use svn to version and commit your linux installation or
part of it. Example directory '/etc'. Very easy you all config files
from '/etc' directory will be saved (backup) and will become under
version control (version control backup solution). Then you could easy
diff or revert any file. etc.
There are some negatives: - regular svn client save data inside '.svn'
directories - svn does not version meta data (modification time, mode,
owner, group. permissions) - when new program is installed, new config
files are created. Their status will be 'unversion files'
fsvs is svn client, trying to solve these negatives. fsvs is using svn
as backend.
There could be more. An example: consider two or more computers with
common programs, common config files. They could share single svn
repository.
Starting from svnhome (http://joey.kitenet.net/svnhome/), I found many
other projects/articles/mail lists:
svnhome, cvshome, etckeeper, git-home-history, vcs-home, etc.
I read a little, many people bother about meta data (permissions,
etc). There are some scripts like commit hook, or run script after
commit/update just to fix the meta data (permissions, etc). FSVS
handle it much better.
I sent email to one mail list, asking them if they hear about fsvs and
what they think. They start argue: which one is better svn or git.
> I mentinoned this before: what if Subversion wants to use the very same
> properties in the future...
And now about the current questions and doubts: Which one is first,
egg or chicken?
Do you think svn developers will annonce soon: 'lets make svn for
administrators and svn for backup... because svn for developers
(source) is very completed and there are no any bugs'?
Negative, I think it could be (maybe soon) especially if people have
chance to try it, if they find it useful and ask for it.
Apart of all above:
If svn decide to use the properties which are already used from fsvs:
1) fsvs could be changed
2) properties in existing 'fsvs' repositories could be very easy
changed
If you decide to show 'custom columns' inside 'tortoisesvn repo-
browser' screen, it could be completely not related to fsvs project.
They could be 'custom columns' and people could use them as they wish
(little like you have bug tracker URL and bug ID and special column in
'svn log' screen).
I do not want to continue this discussion. And I am not in position to
argue or to prove my self. Maybe Stefan arguments are strong enough
(for him), but my priorities and my point of view are different.
Kind regards,
Plamen.
Stefan Küng
> From my point of view, the problem is slightly different. Let me try
> to explain:
>
>
> if programmers use svn to version source files, administrators could
> use fsvs to commit configuration files.
>
[snip]
I never doubted that fsvs was useful. I can see many advantages by using
it (not for me on Windows though).
>> I mentinoned this before: what if Subversion wants to use the very same
>> properties in the future...
>
> And now about the current questions and doubts: Which one is first,
> egg or chicken?
>
> Do you think svn developers will annonce soon: 'lets make svn for
> administrators and svn for backup... because svn for developers
> (source) is very completed and there are no any bugs'?
You're assuming that those properties can only be used for backup tools?
That's not correct. Subversion doesn't have to implement the same as
fsvs - they could make use of those property names for other things.
> Negative, I think it could be (maybe soon) especially if people have
> chance to try it, if they find it useful and ask for it.
>
>
> Apart of all above:
>
> If svn decide to use the properties which are already used from fsvs:
> 1) fsvs could be changed
> 2) properties in existing 'fsvs' repositories could be very easy
> changed
All I'm complaining about is that fsvs uses svn: properties. The
Subversion docs clearly state that these properties are reserved and
only for use by the Subversion lib itself.
Other projects must use other property namespaces. FSVS could use fsvs:
instead of svn:, and everything would be just fine.
Ph. Marek
> >> 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
> * after you created the branch and your initial work, you didn't follow
> through with trying to backport your branch to trunk
There's been so much discussion ... see the summary at
http://svn.haxx.se/users/archive-2008-03/0462.shtml.
> * 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
names:
$ 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
vendor).
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!
Stefan Küng
>> * 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
> http://svn.haxx.se/users/archive-2008-03/0462.shtml.
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.
>> 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?
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
legal troubles.
>>> 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?
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
> 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)? 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
applications.
I'm not saying your bad at coding. I'm just saying your attitude has to
change.
Stefan Küng
> Ph. Marek wrote:
[snip]
Just to clarify the issue here:
You're using svn: properties which you must not. The docs for
Subversion clearly state that svn: properties are reserved for the
Subversion project alone.
The issue here is not so much you using those properties but you
insisting that you have the right to do so and not change the
properties to something else.
You may have noticed that TSVN 1.4.x has problems on Vista. That's
because I too relied on undocumented features without realizing it -
after all, it worked on Win2k and later, it only broke once Vista came
out. But I didn't insist that I was right, instead, I fixed my bugs
and admitted that I did something wrong. Sure, one feature that was
broken on Vista wasn't so much a mistake of mine but the documentation
for that Windows API was misleading. I reported the problem to MS, and
they explained how the API was really meant to be used - but they too
admitted that the docs were not really clear and could be
misinterpreted the way I did, they admitted it and fixed the docs -
and I fixed the bug in TSVN.
You however keep insisting that you have the right to use undocumented
features or do whatever you like with other apps and libraries as long
as your app works. *That's* the problem here. If you would just admit
that you did something you shouldn't have and fix it, all would be
happy.
Ph. Marek
> 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.
> >>> 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
Stefan Küng
>>>> 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.
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.
>>> 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...
Ph. Marek
...
> > 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.
properties (and breaking all existing repositories for all users) I used the
(already registered) name and meaning.
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 I had to take care for the 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?
Stefan Küng
> 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.
mmm4m5m
> 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.
To be honest, I was thinking that this is the case or there is
something like this...
Other way I just can't understand why this discussion is so hot hot
hot.
(Especially your comments Stefan, because they are not good or bad
about TortoiseSVN. Mostly they are bad about FSVS. Different project,
different developers, maybe you never try it, maybe you are not using
linux.)
The reason for this hot discussion definitely is not because FSVS
badly need support from TortoiseSVN. And the answer could be very
simple: "Thank you! Very nice idea, but anyway TortoiseSVN do not plan
to implement such feature. (nice idea about custom columns or maybe
about using SVN for backup and/or version control for configuration
files)"
Also, from my point of view, there is huge difference between
'svn:bugtraq' and 'svn:mode', 'svn:time', 'svn:owner', 'svn:group'.
And that is the reason why you already got answer and the answer is
'NO'. (Sorry.)
regards,
Plamen.
Simon Large
> Also, from my point of view, there is huge difference between
> 'svn:bugtraq' and 'svn:mode', 'svn:time', 'svn:owner', 'svn:group'.
Actually the property is bugtraq:xxx not svn:bugtraq, but that was
probably a typo.
In general I don't think it would be right for TSVN to start adding
support for specific properties for one particular system - where
would that end? But we could bypass all the arguments and polemic
about using "svn:" properties by asking the question a different way -
"Can you customize the CfM columns (and maybe repo-browser) to show
user-defined properties?". If the user chooses to use svn: properties
against Subversion's guidelines then that is their problem. We just
provide a means to display *any* property. That seems to me to be a
reasonable feature request.
The down-side to this in the repo browser, is that AFAIK properties
have to be fetched for each item individually, so adding such
properties could slow the browser down a *lot*. But hey, that's the
user's lookout. They choose to display props and take the
consequences. An improvement would be to have the props fetched in a
separate thread and filled in as they become available, but that might
be just too much work.
Displaying as Explorer columns is not worth the effort as M$ seem to
have phased out custom columns in Vista.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
mmm4m5m
Thank you very much, Simon for your answer.
(if my previous message was offensive - please, excuse me! I really
like and use TortoiseSVN.)
> The down-side to this in the repo browser, is that AFAIK properties
> have to be fetched for each item individually, so adding such
> properties could slow the browser down a *lot*. But hey, that's the
> user's lookout. They choose to display props and take the
> consequences. An improvement would be to have the props fetched in a
> separate thread and filled in as they become available, but that might
> be just too much work.
I am not sure it is a good point, but in case it is useful: in linux
console (command prompt) I to execute two commands in order to get all
property values:
'svn list': it return all files and directories in a folder, each one
on a separate line. Example: 'fileA fileB dirC fileD'
Then I execute second command:
'svn proplist -v fileA fileB dirC fileD': all files provided as
command line arguments.
How much time it would take...
Are these only two request to svn server or it is separate request for
each file/directory...
How much time svn server will take for 'proplist' command...
Is there limitations about 'max length of command' or 'max number of
command line arguments'...
These answers, I do not know. I just gave above example, in case it is
helpful.
Kind regards,
Plamen.
Stefan Küng
> I am not sure it is a good point, but in case it is useful: in linux
> console (command prompt) I to execute two commands in order to get all
> property values:
> 'svn list': it return all files and directories in a folder, each one
> on a separate line. Example: 'fileA fileB dirC fileD'
> Then I execute second command:
> 'svn proplist -v fileA fileB dirC fileD': all files provided as
> command line arguments.
>
> How much time it would take...
> Are these only two request to svn server or it is separate request for
> each file/directory...
That's one request for each listed file. Well, at least one request.
The svn proplist command only returns the name of the property.
Only if '-v' is specified, it will read the value of each property. And
that will take another round-trip to the server for every property.
> How much time svn server will take for 'proplist' command...
> Is there limitations about 'max length of command' or 'max number of
> command line arguments'...
There are limits for command line parameters. But that's not the issue
here (you can write the params to a temp file and just pass the path to
that tempfile instead).
The problem are the many round-trips to the repository which are
required to get (and show) the properties.
It won't be a big problem for repositories on the same LAN, but for
repos hosted somewhere else, this would render the repobrowser useless.
Stefan