info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File permissions


From: Paul Sander
Subject: Re: File permissions
Date: Tue, 25 Sep 2001 17:06:43 -0700

>--- Forwarded mail from address@hidden

>On Tue, Sep 25, 2001 at 03:47:57PM -0400, Greg A. Woods wrote:
>> [ On Tuesday, September 25, 2001 at 21:08:59 (+0400), Tobias Brox wrote: ]
>> > Subject: File permissions

>Kaz Kylheku recently took up my challenge to give *valid* reasons
>not to track file metadata:
>       http://mail.gnu.org/pipermail/info-cvs/2001-September/019853.html
>I'm semi-convinced :-)

There's nothing wrong with adding meta-data.  Just remember that
metadata are data about data; that is, metadata describe data.  In
a version control setting, metadata should not describe process.
We have other mechanisms, such as makefiles, that are perfectly
good at that.

On the other hand, RCS already stores a bunch of metadata:  tags
(both branch and version tags), revision log commentary, per-version
state, text deltas, checkin times, and so on.  All of these describe
the state of a source file at various times, but they do not specify
how to process the source file.  Other things could be added that make
sense:  data type and merge history are obvious examples.

There is a grey area, particularly with regard to multi-part files.
Archive files, Apple's resource forks, and various kinds of documents
that get stored in the filesystem as many files that must tracked as a
unit (e.g. NextStep) come to mind.  Stuff like this can be coded into
a data type handler, which CVS doesn't have at present.  But again, the
metadata describe the data, the type handler implements process.  There
is a difference.

Kaz' exmaples of platform-dependent permissions, make-like rules, and
so on, describe process:  What is done to the file once it's copied out
of the version control system and into the filesystem.

>--- End of forwarded message from address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]