Vizualization of 'fsvs' properties

[mmm4m5m]

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

There is no one GUI fsvs client.

[rblank]

Fixed quoting.

[eblot]

Should be implemented as a plugin, using the IPropertyRenderer interface.

[OT] how fsvs is related to the SVN project?
It seems weird to use 'svn:' property prefix.

wontfix?

[mmm4m5m]

[OT] how fsvs is related to the SVN project?

I am sure someone else could give better answer, but let me try:

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, one example: consider two or more computers with common programs, common config files. They could share single svn repository.

Let me puy it in this way: if programmers use svn to version source files, administrators could use fsvs to commit configuration files.

[eblot]

Replying to mmm4m5m:

[OT] how fsvs is related to the SVN project?

I am sure someone else could give better answer, but let me try:

Yeah, I understand the motivations for this application, but svn: prefix is supposed to be reserved to SVN own metadata (such as svn:log, svn:date, ...).
Applications should use any other prefix, such as fsvs: for instance.

[mmm4m5m]

Replying to eblot:

but svn: prefix is supposed to be reserved to SVN own metadata (such as svn:log, svn:date, ...).
Applications should use any other prefix, such as fsvs: for instance.

As far I know, these properties are ...less or... MORE official :)
...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

[anonymous]

fsvs uses special properties application named
​link

[anonymous]

The link for the FSVS special properties has changed; the documentation has moved to doc.fsvs-software.org: ​http://doc.fsvs-software.org/doxygen-gif/group__s__p__n.html

[anonymous]

And the property names are official now; see the svn_props.h in subversions trunk: ​http://svn.collab.net/repos/svn/trunk/subversion/include/svn_props.h, search for eg. SVN_PROP_TEXT_TIME.

[rblank]

I would be in favor of adding at least the svn:* properties, as they indeed have become official. I'm not sure about the fsvs:* properties, though.

[rblank]

On second thought, and after playing a bit with fsvs and displaying its repository in Trac, I am not sure what needs to be added. I had misunderstood the comments above and thought that the properties were not displayed at all. But the default property renderer shows the property content as text, and property changes in a changeset are displayed correctly already. I don't know what could be made much better.

The only thing remaining from the suggestions in comment:5 is adding columns to the tree view to display the mode, ownerwhip and mtime info, essentially changing the view to a "filesystem" view. This would be specific to projects using fsvs and would not bring any value to the majority of Trac users, and should therefore be done in a plugin.

Closing as wontfix as proposed above.