[Top][All Lists]

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

Re: outsider's perspective

From: Steve deRosier
Subject: Re: outsider's perspective
Date: Tue, 27 May 2003 16:04:10 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

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. Are symbolic links kept and versioned by CVS?

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.

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. :)

Again, the point was missed. It was an example that by combining tools (using make or other build facility), the user could come up with something that would do what it was they were trying to do. And as I recall, isn't that the whole point you've been trying to get across -> use a build facility of some sort to do the parts that CVS doesn't do?

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

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.

- Steve

reply via email to

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