[Top][All Lists]

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

Re: CVS management of /etc - permissions problem

From: Kaz Kylheku
Subject: Re: CVS management of /etc - permissions problem
Date: Thu, 13 Sep 2001 17:35:59 GMT
User-agent: slrn/ (Linux)

In article <address@hidden>, Eric Siegerman wrote:
>On Thu, Sep 13, 2001 at 06:25:34AM +0000, Kaz Kylheku wrote:
>> So you see, it's a fundamental misconception that the conventional
>> metadata on the CVS version files is actually part of the versioned
>> content.
>True enough.
>> If you want
>> something to be versioned, you have to capture it in a file
>> representation, and make sure that file is versioned under CVS.
>Or convince CVS to capture it for you.  That it doesn't do so
>now, and that writing a script is a useful workaround, are not
>valid arguments that CVS *should* not capture and version file
>metadata.  (There may in fact be valid arguments to that effect,
>but these aren't among them.)

A valid argument to that effect is that if CVS were to capture the
metadata, it would probably do so in some text format anyway.  That way
the algorithms for computing text diffs, and for doing merges, would
apply to the versioned metadata in a straightforward way.

To that end, CVS could, for instance, modify the RCS format to allow
for multi-part text files. The normal content would be in one part,
and the metadata representation would be in another part.

This is not really a feature that anyone needs in conventional software
development. You really don't care who owns a C source file, only that
your compiler can read your working or exported copy.

And then there is the problem that you don't necessarily want the metadata
to be applied to your working copy. Suppose you are versioning some
file that goes under /etc and is owned by root, with permissions
rwxr--r-- . Is that what you want your working copy to look like?
Probably not! In what circumstances *is* the metadata applied, then?
If not on checkout, then on export? Or do you make it optional?

What about platform-issues; what do you do with the metadata on a CVS
client platform where it doesn't make sense? Do you handle each supported
platform's metadata in some way, so a file can orthogonally carry metadata
that is applicable in the context of each platform?

It seems as if the ad-hoc methods of versioning metadata are probably
as clean as anything that might be built into CVS; moreover the ad-hoc
methods specifically address a particular user's needs without unnecessary

Then there is the issue that there isn't necessarily a one to one
correspondence between the target objects and the versioned objects
anyway! For example, the target object of a C project may be an
executable file. This does not correspond to any one object in the
repository; it's generated from all the source files. Should there
be a way in CVS to specify the file metadata of that derived object?

reply via email to

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