Re: outsider's perspective
On Tue, 27 May 2003, Greg A. Woods wrote: 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. I agree. By definition, nobody should ``own'' any file in a project. Files are there so they can be shared and worked on by many people. In version control, access control makes sense at the granularity of a whole project: who gets read access to the whole thing, and who gets read-write. A versioned tree is effectively one object. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
--- Forwarded mail from [EMAIL PROTECTED] On Tue, 27 May 2003, Greg A. Woods wrote: 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. I agree. By definition, nobody should ``own'' any file in a project. Files are there so they can be shared and worked on by many people. In version control, access control makes sense at the granularity of a whole project: who gets read access to the whole thing, and who gets read-write. A versioned tree is effectively one object. Many large projects divvy up the code among many developers and prefer to limit write access to specific areas of the repository to specific users authorized to work on that specific code. Sometimes they also globally deny write access to other users, and globally deny all access to still other users. CVS permits this to a degree by using filesystem access permissions in the repository. Many small projects don't want to think about access control, so giving users global read or write access to the repository is adequate for their needs. I've supported both environments with CVS. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
[ On Tuesday, May 27, 2003 at 15:32:49 (-0700), Steve deRosier wrote: ] Subject: Re: outsider's perspective As Don already pointed out, this is very unfair. I don't have any interest working with a project that is held tightly by a very small group of CVS gurus that feel that their way is the only way to do it. The truth is that a small project like CVS (or like a mail transport or any other small program that one programmer can easily understand) is indeed actually best managed and maintained by a very small group of maintainers, or even by one person, provided that the group or the one have a really strong vision of what the program should do (unless they're so lucky as to have a fixed and well defined standard to implement). Even something as big as the Linux kernel would never have succeeded if there were not a very small team of gurus carefully selecting what actualy gets included in it. Why would I spend time trying to learn the CVS codebase and then make changes if I feel that whatever I do is simply going to be summarily rejected anyway? Would you rather pay more money for a commercial product? Would you rather spend more time writing your tools from scratch? It's your decision -- nobody is forcing you to work on and use CVS. With open-source software you are free to adapt that software to your needs without having to start from scratch. You're also free to share your changes, but at the same time other users are free to ignore your changes too. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
outsider's perspective
Well, I want to say thank you to all who posted regarding my query regarding dir versioning. That was a heck of a discussion. My resulting perspective: CVS seems innapropriate for our real world needs, preferring instead to serve a purer versioning paradigm. (A paradigm which, by the way, seems too complex for me to easily understand.) To recap, I was looking for: - the complete history and versioning of every individual file - the ability to recreate dir structures, including hard and symbolic links These 2 things would have allowed me to checkout our whole ERP dir structure as of a given date. Sweet! Greg says to use the right tool for the right job. Well, I wish CVS were the right tool, because the two right tools I've read about have real problems! ClearCase: ClearCase costs a lot of money. I mean a *lot* of money. Now, my organization might pay for it, or they might not, I don't know. We are a University in the USA, so we do have money. But I guarantee most of this world would never in a million years be able to pay that sort of money. So while my org might get by, the rest of the world suffers for the lack of an open source solution. My own custom build tool, wrapped around CVS: Gimme a break. It's taken our ERP vendor a decade (more?) to evolve their current ... um... way of doing things. I'm pretty good at hacking and munging, but I am not prepared to try and automate all of the linking and the recreation of the other inconsistent results of their upgrade scripts upon CVS checkout. No, I need a tool that can simply capture the *results* of their way of doing things and leave it at that. In conclusion, I know I have little choice but to follow Greg's advice. I'll use CVS for my little perl modules, but I'll be sorry to report to my boss that CVS won't work for our ERP versioning project. Phil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
Have you looked at subversion? Or what about bitkeeper? I'm pretty sure that subversion can handle directory versioning. I don't know about bitkeeper as that I refuse to download the source due to their restrictive liscensing agreement... donald On Tue, May 27, 2003 at 08:50:02AM -0500, Phil R Lawrence wrote: Well, I want to say thank you to all who posted regarding my query regarding dir versioning. That was a heck of a discussion. My resulting perspective: CVS seems innapropriate for our real world needs, preferring instead to serve a purer versioning paradigm. (A paradigm which, by the way, seems too complex for me to easily understand.) To recap, I was looking for: - the complete history and versioning of every individual file - the ability to recreate dir structures, including hard and symbolic links These 2 things would have allowed me to checkout our whole ERP dir structure as of a given date. Sweet! Greg says to use the right tool for the right job. Well, I wish CVS were the right tool, because the two right tools I've read about have real problems! ClearCase: ClearCase costs a lot of money. I mean a *lot* of money. Now, my organization might pay for it, or they might not, I don't know. We are a University in the USA, so we do have money. But I guarantee most of this world would never in a million years be able to pay that sort of money. So while my org might get by, the rest of the world suffers for the lack of an open source solution. My own custom build tool, wrapped around CVS: Gimme a break. It's taken our ERP vendor a decade (more?) to evolve their current ... um... way of doing things. I'm pretty good at hacking and munging, but I am not prepared to try and automate all of the linking and the recreation of the other inconsistent results of their upgrade scripts upon CVS checkout. No, I need a tool that can simply capture the *results* of their way of doing things and leave it at that. In conclusion, I know I have little choice but to follow Greg's advice. I'll use CVS for my little perl modules, but I'll be sorry to report to my boss that CVS won't work for our ERP versioning project. Phil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
Phil, As you know, CVS doesn't version directories and frankly was never designed with that in mind (never mind the argument over if it should or should not, it simply doesn't). But...there is a program that does record directory structure: tar. Perhaps you could somehow use tar in conjunction w/ CVS to do what you want to do. OR Alternatively, since you're a Perl programmer, why not just write a simple script to parse the directories. You could write two scripts: Script1.pl - This one recursively parses the directories, writing a file (or to stdout) a representation (in text, best if easily human readable) of the directory structure. Script2.pl - This one parses the representation file and creates the directory structure. The representation since it is in text _could_ and in this scenario _should_ be checked into CVS and properly versioned. There may be a way to get CVS to handle a ci and co of the full ERP system using these scripts and the wrappers (not sure, I've never used the wrappers), but if not, you could always have a project 'ERP' that contains a Makefile and the representation file. You checkout the ERP module, run make, and boom, you've got your whole ERP retrieved from the repository. The Makefile would have the instructions to: 1. run Script2.pl on the representation file and build the ERP directory structure 2. run the necessary CVS co or export commands to grab the required files and put them in the right places. Maybe your Makefile could have both a ci and a co target so you could run 'make co' and 'make ci' to do what you want to do. Anyone with some competence in Perl and make should be able to build this little build environment in a few days (and don't ask me, I already have a full time job). Do it in house or hire a consultant. (And don't forget to check the scripts into CVS while you're at it). But, you've got to decide on a trade off - pay the big bucks for ClearCase or pay (either time or money) to have someone build you a custom build environment. And, you need to evaluate ClearCase to decide if it really does what you are trying to do, or if you're going to have to bend to their way of doing things. I don't know, I have no experience or knowledge with ClearCase at all. Really, this was all anyone was trying to suggest when they said that CVS doesn't do directories and you'd have to use a build tool to handle them (and frankly, this is the 'proper' way to do it from the CVS paradigm). As to the CVS paradigm, it's pretty simple: CVS versions files (text files primarily) and allows for multiple people to checkout and edit those files concurrently. CVS doesn't think anything about directory structure except that it is possible to nest Modules within one another. (Frankly it seems to work best and is happiest when the directory structure is relatively flat.) Directories have no purpose other than to be containers for files (which CVS does care about and will version) and as such, other than structure and name, are so un-interesting to be beneath notice. That's it. Don't think too hard on it. As is typical with Linux and other UNIX systems, CVS is a simple tool meant to do one simple job and nothing else. CVS versions files. If you want to do more, add more tools into the mix (tar collects files and directories into one large file, but doesn't compress them; gzip compresses single files but doesn't collect them; together the two can grab and archive a large swath of the filesystem and make it small enough to fit on one CD). I don't know if any of this helps, but I hope I gave you an idea that you hadn't considered. - Steve Phil R Lawrence wrote: Well, I want to say thank you to all who posted regarding my query regarding dir versioning. That was a heck of a discussion. My resulting perspective: CVS seems innapropriate for our real world needs, preferring instead to serve a purer versioning paradigm. (A paradigm which, by the way, seems too complex for me to easily understand.) To recap, I was looking for: - the complete history and versioning of every individual file - the ability to recreate dir structures, including hard and symbolic links These 2 things would have allowed me to checkout our whole ERP dir structure as of a given date. Sweet! Greg says to use the right tool for the right job. Well, I wish CVS were the right tool, because the two right tools I've read about have real problems! ClearCase: ClearCase costs a lot of money. I mean a *lot* of money. Now, my organization might pay for it, or they might not, I don't know. We are a University in the USA, so we do have money. But I guarantee most of this world would never in a million years be able to pay that sort of money. So while my org might get by, the rest of the world suffers for the lack of an open source solution. My own custom build tool, wrapped around CVS: Gimme a break. It's taken our ERP vendor a decade (more?)
Re: outsider's perspective
[ On Tuesday, May 27, 2003 at 11:39:22 (-0700), Steve deRosier wrote: ] Subject: Re: outsider's perspective As you know, CVS doesn't version directories and frankly was never designed with that in mind (never mind the argument over if it should or should not, it simply doesn't). But...there is a program that does record directory structure: tar. Perhaps you could somehow use tar in conjunction w/ CVS to do what you want to do. CVS already does effectively what tar does, and it already does it with support for recording the addition and deletion of files temporally, something which tar obviously cannot do. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, 27 May 2003 14:24:50 -0400 Donald Sharp [EMAIL PROTECTED] wrote: Have you looked at subversion? Or what about bitkeeper? I'm pretty sure that subversion can handle directory versioning. Yeah, subversion looks promising, but symbolic links aren't slated for inclusion untill after version 1.0, and I didn't see anything about Hard links. Thanks for the tip on bitkeeper, though. I emailed their staff just now. We'll see what they have to say. Phil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, 27 May 2003 11:39:22 -0700 Steve deRosier [EMAIL PROTECTED] wrote: That's it. Don't think too hard on it. As is typical with Linux and other UNIX systems, CVS is a simple tool meant to do one simple job and nothing else. CVS versions files. If you want to do more, add more tools into the mix You know, that does paint a rosier, and fairer picture. I believe in the usefulness of using the pipe on the command line, and this does seem analogous. Thanks! As for the perl wrappers, yeah, I had gone as far in my thinking as you did in your note. The hangups start when considering how to determine at checkin time which of the n hard links will become a file actually stored in CVS, and how to track the other hard links to be sure they are updated upon checkout. I suppose that's doable also, but... how much hacking and wrapping is too much? I guess that's another tradeoff. Piping this to that to the other on my own personal command line is one thing, but this will be an scm system to be used by one and all. Some in my department are known to be set in their ways, and complexity is anathema. When I began looking into CVS, the complexity of the tagging/branching syntax was almost enough to make it a non-contendor for our users. I'll keep looking for now. Thanks again for your fair(er) thoughts on CVS. Phil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, 27 May 2003, Steve deRosier wrote: Alternatively, since you're a Perl programmer, why not just write a simple script to parse the directories. You could write two scripts: Script1.pl - This one recursively parses the directories, writing a file (or to stdout) a representation (in text, best if easily human readable) of the directory structure. Script2.pl - This one parses the representation file and creates the directory structure. The representation since it is in text _could_ and in this scenario _should_ be checked into CVS and properly versioned. Or you could just Meta-CVS, which has been out well over a year. You have the basic idea right, but it takes more than a handful of perl scripts to make robust, smooth version control application that takes care of the corner cases and error situations. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, 27 May 2003, Phil R Lawrence wrote: Date: Tue, 27 May 2003 10:16:00 -0500 From: Phil R Lawrence [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: outsider's perspective On Tue, 27 May 2003 14:24:50 -0400 Donald Sharp [EMAIL PROTECTED] wrote: Have you looked at subversion? Or what about bitkeeper? I'm pretty sure that subversion can handle directory versioning. Yeah, subversion looks promising, but symbolic links aren't slated for inclusion untill after version 1.0, and I didn't see anything about Hard links. When I heard that the SVN guys were planning symlinks, I took the two days of effort to put them into Meta-CVS. It took some huffing and puffing, but it was worth it. I ended up using them in a couple of projects. Meta-CVS could in principle support hard links as well. I can visualize quite crisply how it would work, but I currently have no incentive to do the work. If I think that something is useful to the product (i.e. *I* can use it myself, or it provides some strategic advantage) then I might put it in. It shouldn't take more than around four 40 hour developer-weeks to do it (and I mean do it right, so that every operation is properly aware of hard link support, including ``mcvs grab''). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
Greg, I wasn't trying to indicate that tar was the perfect tool for this, or even that it was or might be the right tool. I was simply suggesting that trying multiple tools in sequence might accomplish what was desired. tar was simply an example suggestion of a place to start looking. But, I would disagree that CVS already does effectively what tar does... No, tar creates a single binary file for archive purposes. CVS does not do this. Also, tar DOES handle directory information and can preserve owners, permissions and all other directory meta-info. CVS does not do this. 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. I've been lurking on the list for a very long time, and it seems to me that the one of the largest perceived deficiencies with CVS is it can not handle directory meta information (in other words, it can't version directories). Perceived because some people consider this a deficiency while others consider it the right way. Now, I'm not willing to debate if CVS is right or wrong in this, but it must be conceded that CVS doesn't do this, and as such may not be right for everyone. I've never needed the functionality, so I don't have an opinion on it one way or another. Regardless, it doesn't really matter. CVS doesn't do as the poster wants. There may be ways to handle it using CVS + some other standard Linux tools, or maybe the poster will just need to move on to another tool. Also, if so many people NEED this functionality, why doesn't it get added to CVS? If people only THINK they need it, then why don't we tell them how to do what it is they are actually trying to accomplish while using CVS? Maybe this NEED is real, and maybe it's just marketing from commercial version control companies, but one way or another it gets asked for. Giving people on this list the usual if it doesn't work for you, well #*@ you, go somewhere else rant seems counter-productive. Perhaps if we all discuss it calmly and logically, we can find a way to give people what they want and remain true to the CVS-way. Some of the stuff on this list lately is beginning to look like a religious war, instead of useful discussion. Thanks, - Steve Greg A. Woods wrote: [ On Tuesday, May 27, 2003 at 11:39:22 (-0700), Steve deRosier wrote: ] Subject: Re: outsider's perspective As you know, CVS doesn't version directories and frankly was never designed with that in mind (never mind the argument over if it should or should not, it simply doesn't). But...there is a program that does record directory structure: tar. Perhaps you could somehow use tar in conjunction w/ CVS to do what you want to do. CVS already does effectively what tar does, and it already does it with support for recording the addition and deletion of files temporally, something which tar obviously cannot do. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, 27 May 2003, Steve deRosier wrote: Also, if so many people NEED this functionality, why doesn't it get added to CVS? One reason is that it doesn't have to be literally added into the CVS program, but rather imposed on top of it. CVS can be used as a subprocess in a version control system that has the functionality. This is a legitimate way of creating a ``CVS II''. In fact, this approach is better in many ways than hacking inside CVS. Separate processes provide fault isolation, and avoid forking the codebase. If ``CVS II'' has a bug that stems from CVS, you just upgrade CVS to the bugfixed version. It's blackbox inheritance! CVS gives us the ``base class'' which we ``override'' to the get ``CVS II'' behavior with versioned directories, symbolic links, permissions, etc. There are a few drawbacks. The command line interface sometimes is less than ideal, and also systems impose limitations on its length, so the ``CVS II'' layer sometimes has to break up long command lines, turning one logical CVS operation into multiple actual ones. Another problem is that the output of the CVS process sometimes has to be passed through a text filter so that it makes sense at the ``CVS II'' level. Doing the substitutions in CVS itself would mean altering its code. ``CVS II'' has already been written, and released almost 1.5 years ago, but you see, it was unfortunately named ``Meta-CVS'', and so people somehow don't see it as a proper sequel. If the sequel to The Matrix was called ``Riemann Sphere'', perhaps few would get it either. Meta-CVS does directory structure versioning, and other things. but it's not CVS II! Why? Because it's not *called* CVS II, and besides, it's not backward compatible. Never mind that it uses CVS for everything: branching, merging, diffing, annotating, viewing logs etc. and that it's nearly command-for-command compatible. What it stores in the CVS repository can't be grokked by CVS I clients. (Just like ANSI C programs can't be grokked by KR compilers; are those programs not written in C?) Okay, so if this is not legitimate, let's hear a concrete plan about how CVS can be extended to make a ``CVS II'' which is completely backward compatible with CVS I clients, and works as well as Meta-CVS. Better yet, let's see some code. It's not enough to propose alternative ideas when the existing idea is already coded. The CVS mailing list has seen more than a *decade* of idle discussions about this subject already. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
[ On Tuesday, May 27, 2003 at 14:07:18 (-0700), Steve deRosier wrote: ] Subject: Re: outsider's perspective But, I would disagree that CVS already does effectively what tar does... No, tar creates a single binary file for archive purposes. CVS does not do this. Also, tar DOES handle directory information and can preserve owners, permissions and all other directory meta-info. CVS does not do this. 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. CVS does already partly handles the one permission bit that's meaninful to copy from the repository, for what it's worth (almost nothing in practice). 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. 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?!?!?!? 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? -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
On Tue, May 27, 2003 at 02:45:14PM -0700, Kaz Kylheku wrote: On Tue, 27 May 2003, Steve deRosier wrote: Also, if so many people NEED this functionality, why doesn't it get added to CVS? One reason is that it doesn't have to be literally added into the CVS program, but rather imposed on top of it. CVS can be used as a subprocess in a version control system that has the functionality. This is a legitimate way of creating a ``CVS II''. In fact, this approach is better in many ways than hacking inside CVS. Separate processes provide fault isolation, and avoid forking the codebase. If ``CVS II'' has a bug that stems from CVS, you just upgrade CVS to the bugfixed version. It's blackbox inheritance! CVS gives us the ``base class'' which we ``override'' to the get ``CVS II'' behavior with versioned directories, symbolic links, permissions, etc. There are a few drawbacks. The command line interface sometimes is less than ideal, and also systems impose limitations on its length, so the ``CVS II'' layer sometimes has to break up long command lines, turning one logical CVS operation into multiple actual ones. Another problem is that the output of the CVS process sometimes has to be passed through a text filter so that it makes sense at the ``CVS II'' level. Doing the substitutions in CVS itself would mean altering its code. ``CVS II'' has already been written, and released almost 1.5 years ago, but you see, it was unfortunately named ``Meta-CVS'', and so people somehow don't see it as a proper sequel. If the sequel to The Matrix was called ``Riemann Sphere'', perhaps few would get it either. Meta-CVS does directory structure versioning, and other things. but it's not CVS II! Why? Because it's not *called* CVS II, and besides, it's not backward compatible. Never mind that it uses CVS for everything: branching, merging, diffing, annotating, viewing logs etc. and that it's nearly command-for-command compatible. What it stores in the CVS repository can't be grokked by CVS I clients. (Just like ANSI C programs can't be grokked by KR compilers; are those programs not written in C?) Okay, so if this is not legitimate, let's hear a concrete plan about how CVS can be extended to make a ``CVS II'' which is completely backward compatible with CVS I clients, and works as well as Meta-CVS. Better yet, let's see some code. It's not enough to propose alternative ideas when the existing idea is already coded. The CVS mailing list has seen more than a *decade* of idle discussions about this subject already. In some respects I think this last paragraph is unfair. I've seen lots of different ideas over the last couple of years that get squashed loudly whenever they are brought up. Why would people want to contribute when there is no interest in changing cvs. Or when people do show interest they get yelled at for not doing it the 'pure cvs' way. donald ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
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 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. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: outsider's perspective
--- Forwarded mail from [EMAIL PROTECTED] 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
Re: outsider's perspective
[ On Tuesday, May 27, 2003 at 14:45:14 (-0700), Kaz Kylheku wrote: ] Subject: Re: outsider's perspective One reason is that it doesn't have to be literally added into the CVS program, but rather imposed on top of it. CVS can be used as a subprocess in a version control system that has the functionality. This is a legitimate way of creating a ``CVS II''. Note that the CVS we're talking about these days _is_ literally called ``CVS-II'' The first CVS was implemented as a set of shell scripts. See the paper. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
