Re: outsider's perspective

[Paul Sander]

>--- Forwarded mail from address@hidden

>> No concurrent versioning system with a shared repository, and
>> particularly not one that can operate in a client/server mode, can ever
>> possibly make any use of ownership, nor even of most permissions bits.
>> Ownership information, and most permissions bits, "MUST" always be
>> specific to the client and it MUST NOT be dictated by the repository.

>Yes, this makes perfect sense, and I agree with you.  Frankly I'm not 
>even sure what it is that various people are asking with keeping the 
>other meta info.  But it seems that there are other bits (not as in 1s 
>and 0s) of meta information that people want to keep about directories. 

Metadata I can think of off the top of my head:
- Mapping to the history containers (RCS files) of its contents.
- Access controls (who can update, who can commit).
- Execute permissions.

CVS actually maintains all of this stuff in very primitive ways.  At one
time or another every one of them has been pointed out has being deficient
in CVS in some way.

>  Are symbolic links kept and versioned by CVS?

Nope.  Arguments go both ways as to whether or not they should be.  I
personally believe they should not be (for portability reasons).

>> If people would learn two things then all this stupidity would disappear
>> in a puff of smke:  (1) CVS is a text file content change tracking tool, and
>> _only_ a text file content version tracking tool; (2) all these things
>> (file permissions, ownerships, symbolic and hard links, etc.) can far
>> FAR more elegantly, simply, and clearly be managed by a build script,
>> the source for which can be stored in CVS.

>Again, I agree with your point of (1).  Also, I think that a build 
>script is a good way to handle things (but I've always been a huge fan 
>of the power of make and use it for many things beyond just building my 
>latest C/C++ projects).  But, what about large directory structures of a 
>web site?  The directory information is meaningful.  And the person 
>doing the maintaince can't always login as the psudouser the web server 
>runs as.  And a build script isn't necessarilly meaningful in this 
>context either.

I agree that CVS *is* an ASCII text file version tracking tool.  I disagree
that it *must be* only an ASCII text file version tracking tool.  All it
needs to lift this restriction is to remove the hard-coded invocations of
diff and diff3 in the user interface, replacing them with a more general
tool that adapts to the data type.  I've already demonstrated that this can
be done by posting a patch to this forum on or around Sept. 18, 2001.

As for the rest:  There's a difference between building a project and
deploying it.  Sometimes a build procedure does both (e.g. with a "make
install" target).  Other procedures build a project in a way that it can
be tested and as a side effect produce data that drive the installation
(e.g. files that drive the creation of installable packages).  The
installers should solve the problems of permissions and access controls
on the deployed product.  Shops are usually receptive to building the
necessary infrastructure to have appropriate people run the installers
successfully.

>>> tar DOES NOT handle versioning or history 
>>>information.  CVS does do this.  I was suggesting that somehow combining 
>>>the two tools it may be possible to create a system that did what he was 
>>>looking for.
>> 
>> How do you expect to meaninfully combine a tool that creates binary
>> files with CVS?!?!?!?

>Frankly, I felt that was an exercise for the reader.  But one idea (not 
>necessarily the best idea or even a good idea) was the user could tar up 
>the directory structure and put the tar archive into CVS (using the 
>approprate -k flag of course).  I would think you'd want to separtely ci 
>your text files that were in those directories though so the changes 
>could be tracked better.  Perhaps not good and maybe not any better than 
>just keeping a directory with date-munged-file-named tar files.  As I 
>said, example and not a good idea.  :)

I think that if you're going to tar up a bunch of files and store them in
CVS then you're probably better off just storing the files themselves.
There are exceptions, of course (NextStep being one of them).  And in these
cases, its appropriate to use merge tools tailored for tar files.  (Yes,
you can do 2- and 3-way diffs on tar files, and 2- and 3-way merges.  I
believe these can even be automated for interactive and non-interactive
use in the "CVS" way.)

>>>Also, if so many people NEED this functionality, why doesn't it get 
>>>added to CVS?
>> 
>> Have you not been paying any attention to the rationales I and others
>> have given for why CVS is the way it is and why it doesn't do some
>> things?

>Of course I have been.  Considering that the same song and dance has 
>been done here regularly to avoid making meaningful improvments in CVS, 
>I could hardly miss it.  Many of the rationales are perfectly valid, but 
>sometimes it sounds like you (and others) are rationalizing out a reason 
>it can't be done simply because you don't want it to be done.  I'm often 
>guilty of the same thing :) , but maybe we should try to be honest with 
>ourselves and try to come up with a VISION of what CVS should be and 
>where it should go in the future.  These problems and questions won't 
>stop simply because we rationalize that CVS was designed to solve this 
>set of problems but not that set.

>I agree that CVS is for versioning text files.  But there are many text 
>files formats (XML, HTML, RTF and so on.  All are text files.).  And 
>some of these do depend on directory structure to be meaningful.  And 
>some of these are occasionally not handled properly by CVS if the 
>reports on this list are any indication.

>CVS is great, and it handles text files fine.  But putting arbitrary 
>roadblocks in front of your users defeats the whole purpose.

Well said, if only "s/text file/file/g".  :-)

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