I think it is a great idea to standardise on some common names for
I've been using the following properties for recording extra filesystem
information. I'm not overly happy with the names that I called the
properties but since I have a number of repositories that are using
these names now I couldn't be bothered to change them. I use a wrapping
script called asvn to version control entire unix file systems. I posted
a copy of the script last year here
pretty much use the same script today.
Assigned to a directory and lists the device files that it contains. The
format I use is one line per entry with entry of the format
file='<filename>' mode=<octal mode> user=<name>(<uid>)
group=<name>(<gid>) type=<device type> major=<id> minor=<id>
ie file='watchdog' mode=644 user=root(0) group=root(0) type=c major=10
Assigned to a directory listing all the symlinks that it contains. One
entry per line of the format.
ie file='modem' dest='ttyS1'
Assigned to either files or directories to define the uid, gid and
access mode. This is equivalent to the proposal below of svn:unix-owner,
svn:unix-group and svn:unix-mode but all rolled into one entry with the fmt.
mode=<oct mode> user=<name>(<uid>) group=<name>(<gid>)
ie mode=755 user=root(0) group=root(0)
Ph. Marek wrote:
>3 - Properties I'd like to propose, so that clients have a common
>understanding of them.
>Note: they point in the direction of using svn as a backing store for backup
>and restore - as that's where I'll try to use subversion in the future.
>----- svn:unix-owner, svn:unix-group
>Both could be in the form of "name (number)". The name should be used, if not
>accessible, the id.
>Of course that would be useable only for uid's 0 - other could just commit
>this info for files.
>Records the unix-permissions (in the octal form of 0755, 02750 (group sticky
>bit), and so on)
>Stores the windows-acl's in a similar form to svn:unix-mode.
I don't think it is my place to say but unless the main svn code sets
these properties I don't think they should be in the svn name space.
Personally I don't see any reason for the main svn code to record this
information. What might be nicer is for the svn code to call external
hooks scripts on the client for any checkin/update action it performs
which in turn could act on the properties if needed.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 18 01:58:50 2004