Re: BRANCH LABEL FOR DIRECTORIES
Greg's comments generally fall under the That's by design category but it's not obvious that that design is good. Every team needs someone who is passionate about protecting the elegance of the original design and not succumbing to creaping-feeturitis. For this reason, I'm very, very glad that Greg is here. However, I do tend toward the notion that a revision control system should automatically track important events in the lives (plural, given branching) of every file it contains, including merges, moves, and renames. Not supporting these affects the continuity of the history, which in turn affects automated operations like subsequent merges. I've been working lately with a SCM tool that versions directories and I've found that it makes life much easier (at least with regards to renames and branching). If it is possible to truly track directory changes by inference from file changes, I'm all for it. Directory tracking is problematic in a variety of ways, as it is in some sense a second view of some of the same data. I suspect that the imperfections in directory tracking you've experienced may a side-effect of imperfections in tracking file movement and renaming. If these are done correctly, it should be possible to infer directory behavior from them. The two directory changes that I can think of that can't be inferred from properly tracked file activity are creation and deletion; the only effect of this is that an empty directory is indistinguishable from an absent one. I think accurately tracking the existence of empty directories is the least of CVS's limitations, so I'm willing to let that one go. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
cp olddir/oldfile.c newdir/newfile.c cp olddir/oldfile2.c newdir/newfile2.c cvs rm -f olddir/* cvs add newdir/newfile.c newdir/newfile2.c cvs commit -m 'reorganized source to be better' cvs update -P However I can't let that sit. What a downright stupid and misleading example. This doesn't seem like a manufactured scenario to me - more like something that comes up every so often, although I'll admit it has fewer files than the normal case. It looks like what I would do if you had to move the contents of a directory from one place in the directory tree to another? How would you do it, Greg? It isn't enough to say that you simply wouldn't let this happen to you. Migrations, even mass migrations, are a fact of life; demands of logistics often place their prevention beyond our control; since they cannot be prevented, they need to be supported without damaging continuity. CVS isn't a market driven product -- it's a freeware niche product. I don't see CVS as a niche product at all. CVS is as mainstream as Linux or Java. Most of what most people need is easy to learn and use, with the exception of branches and merges. Set up is kind of fragmentary, as for many Linux services, but it seems to have all the right hooks in all the right places for integration into corporate build mechanisms. Its support for Windows clients is adequate. As companies become more accustomed to shareware, I could see it become the preferred version control system for corporate Unix/Linux. If the Windows version could register out of the box as a Win2000 service, I could see it becoming popular for Windows shops, too. Its biggest drawback as a mainstream product is that branching and merging require you to know a lot more than with other products and require certain voluntary behaviors that aren't immediately obvious, like tagging on both branches when doing merges. A few enhancements, like tracking moves, renames, and merges will permit reasonable default behavior in most situations for those developers who do not have a passionate interest in revision control. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
[ On Tuesday, June 19, 2001 at 08:50:34 (-0400), Ralph Mack wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES cp olddir/oldfile.c newdir/newfile.c cp olddir/oldfile2.c newdir/newfile2.c cvs rm -f olddir/* cvs add newdir/newfile.c newdir/newfile2.c cvs commit -m 'reorganized source to be better' cvs update -P However I can't let that sit. What a downright stupid and misleading example. This doesn't seem like a manufactured scenario to me - more like something that comes up every so often, although I'll admit it has fewer files than the normal case. It looks like what I would do if you had to move the contents of a directory from one place in the directory tree to another? There are two differences between Paul's example and the one I gave. One of those differences is irrelevant to this issue, and the other is critical. The irrelevant difference is the use of two files moving from one sub-directory to another (and the implication that maybe the directory is also being renamed, though that's not necessarily what's happening). The critical difference though is the meaningless and useless commit and perhaps misleading comment in Paul's example. How would you do it, Greg? I gave a more meaningful and future useful commit comment in my example. Paul's example is probably less useful and more misleading than if it were simply left empty. At least an empty comment can be more easily flagged for correction! ;-) A future useful commit comment is something that's critical for every commit in every revision control system, not just one that removes or adds one or more files, of course. It's very important for the committer to always ask themselves the question Does my explanation clearly and completely describe this change to some future maintainer who is trying to understand it and its intent? Paul's message might be sufficient in the form of an e-mail message that includes all the file names and all the actions (such as one that might be produced by the log_accum loginfo script). However to anyone in the future examining any of the revision histories of any of those individual files, it will not only be incomplete, but it might even be misleading. The only thing special about commit messages for renamed/moved file(s) in CVS is that they have to be somewhat redundantly worded if they're to be used identically for both the removed and the added file(s). However I don't think they're very hard to devise for anyone willing to take a moment to think about what they're writing. CVS is not a replacement for good inter-developer communications, though sometimes it is the vehicle. It isn't enough to say that you simply wouldn't let this happen to you. Migrations, even mass migrations, are a fact of life; demands of logistics often place their prevention beyond our control; since they cannot be prevented, they need to be supported without damaging continuity. Once burned, twice shy? Certainly learning from one's mistakes is painful. Luckily in this case the commit messages can be changed after the fact, at least so long as it is caught before the committer disappears or forgets what he or she did. I don't see CVS as a niche product at all. CVS is as mainstream as Linux or Java. It really doesn't matter how widely used CVS is -- it's popularity is simply an indication of how commonly people do the things it can do (and perhaps how commonly people try to use it to do things it cannot do well). CVS is a niche product because it offers only those specific features necessary for tracking the change history of source code (including the source text that might be used to produce documentation), and because it helps solve a couple of common problems often encountered by users of more traditional source control systems such as RCS or SCCS. CVS is a niche product because it explicitly, by design, does not attempt to provide a generic change control system that can be used in _all_ scenarios where it is useful to track changes to files stored on a computer system. CVS is a niche product because it does not need a large market share in order to survive (it could survive quite well if only one person used it). Most of what most people need is easy to learn and use, with the exception of branches and merges. Set up is kind of fragmentary, as for many Linux services, but it seems to have all the right hooks in all the right places for integration into corporate build mechanisms. Its support for Windows clients is adequate. As companies become more accustomed to shareware, I could see it become the preferred version control system for corporate Unix/Linux. If the Windows version could register out of the box as a Win2000 service, I could see it becoming popular for Windows shops, too. Lots of people would no doubt disagree with at least your claim that CVS has all the right hooks in all the right places. Indeed there's another thread going on right now
Re: BRANCH LABEL FOR DIRECTORIES
Greg A. Woods wrote: Ah, but in this case I can. Everything I've described about tracking the renaming/moving of files using cvs rm and cvs add with magically meaningful comment strings can be easily automated by a front-end. No change is necessary in CVS itself to achieve this functionality, therefore it is provably not a necessary feature of the basic CVS functionality. I agree, although I might argue that if you were the person who were going to add this functionality, the most efficient place to add it would be on the CVS server since it shouldn't require any client support and adding the functionality to the server should make the feature immediately available to most clients on most platforms. Besides, storing metadata in log messages is rather messy. Of course a wrapper implementation could make the feature available on a server that didn't otherwise support it, but I'd consider that mostly moot since most of the other features and bug fixes that make it into new CVS releases can usually justify upgrading. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- As honest as the day is long. - S. Z. Sakall as Headwaiter Carl, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
[ On Monday, June 18, 2001 at 00:51:22 (-0700), Paul Sander wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES No, it doesn't delete it, but it does hide the old stuff (which is just as bad). Once the remove-add sequence is done, there is no reliable method to track down the original location, and under some circumstances there may even be no way for the end user to recover it. NO, it does not hide it either. Any semi-sentient being can find it in no time at all. I beg to differ. Even in your preferred method, you rely on the user to carefully leave a bread crumb trail, by noting the rename in the commit comment. The audit trail is not necessarily dependent on the user -- there are an almost infinite number of ways to mechanise and automate its creation (and its tracking too)! The version control system should track the rename separately, in the version history but separate from the user's comments. Why? There's no logical difference. You're kidding, right? Don't support merging across renames? This capability is one of the most basic requirements of any version control system worthy of the name. I think you're living in a dream world of marketing driven featuritis. I've been using CVS intensively for how many years now? Eight? I've *NEVER* had any major problems with renames, and I don't just avoid them. What if you rename the top directory of a deep tree? That's a LOT of manual merging to do. Why would anyone do anything so idiotic? And sometimes the rename is necessary. No, such things are *NEVER* necessary! It's a figment of your imagination. It might be highly desirable, but never ever necessary. And sometimes the users expect the rename operation to be both reversible and repeatable. CVS does not provide this capability in any sense. Ha! Of course some users, such as perhaps yourself, have totally unrealistic expectations. That's the nature of the game. CVS isn't a market driven product -- it's a freeware niche product. You're comparing apples and oranges and then wondering why there's no consistent taste between the two. Okay, let's pick nits and say only that the format of the data contained in a file changes. Let's say that it changes from RTF to HTML. Strictly speaking, the file's type does not change, but using CVS in the normal way produces gibberish in certain cases that are easy for the average user to fall into. Users who do idiotic things like that will get stupid results. G.I.G.O. CVS is not a system for button pushing automatons -- you have to think to use it properly. This just would not happen if version histories tracked the entire lifetime of a file, not just that portion of its life when it occupied one spot in the filesystem. Fine. Go use such a system and forget you ever heard about CVS. Or, CVS could be changed to really do it right... In your dreams Paul. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
[[ I'm not going to get dragged into a stupid debate about comparing apples and oranges in this silly filesystem analogy. The only things more pliable to one's needs than analogies are probably statistics. You can't prove anything with them -- they're only usefule as illustrations. ]] [ On Monday, June 18, 2001 at 01:25:28 (-0700), Paul Sander wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES Okay, now consider this: cp olddir/oldfile.c newdir/newfile.c cp olddir/oldfile2.c newdir/newfile2.c cvs rm -f olddir/* cvs add newdir/newfile.c newdir/newfile2.c cvs commit -m 'reorganized source to be better' cvs update -P Guess what: The old revision history is now hidden from the user. To see the revision history of either of either file prior to the rename, he must figure out what tags (if any) have been applied to the files prior to the rename, use one of them to check out the module, and bounce back and forth between the two workspaces to see everything. However I can't let that sit. What a downright stupid and misleading example. Paul you can continue to manufacture stupid scenarios to try to prove your point of view, but nobody's buying it. Yes the documentation should be improved so that users have no excuse for doing that kind of nonsense. Luckily such mistakes can be easily corrected after the fact (at least within the timeframe of the committer's memory). Except that in CVS the revision history does not remain in place; a new RCS file has been created, and it is modified from that time forward while the old one is ignored. You're looking under the hood again -- I thought I told you not to do that! Use your imagination! Pretend all combinations and permutations of RCS files exist all the time. In that case, your requirements are really simpler than most. Don't try to tell me what I'm doing -- you're not sitting here watching me day in and day out and you have no access to my past and present projects. Yeah, you replaced renames with repeatedly re-importing your sources into clean modules, right? No! You're not paying attention and your making incorrect assumptions. I worked on the Unix System V (both the definitive and the Solaris variants) for four years, and in that time I experienced no fewer than two significant reorganizations in each, all fed from offsite. The teams I worked with required the complete version history of every file to be immediately accessible from their workspaces so that they could use cvs log and cvs update -j without thinking about how to find the same file in some other place that it occupied prior to a reorg. Not having that capability was a tremendous hardship. You must live with the circumstances you create for yourself. Sounds like so much disjoint change was introduced without planning that it took more effort to try and manage the result after the fact than proper planning ahead of time would have taken. Yes code maintenance is sometimes hard, but it doesn't have to be a tremendous hardship no matter what tools you have to work with (even if it's just pencils and graph paper!). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
[ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES So why not have CVS do this work OOTB? You could. It's been proposed several times before. Nobody's stepped up to write the code. Even though I've also proposed it in the past, my proposal was in response to someone else's problem and of late I've not even had time to implement the solutions to my own problems, let alone anyone else's! ;-) It should be quite trivial to add such rename functionality to any of the more advanced font-ends to CVS (be they either stand alone clients, or wrappers that just call the existing command-line client). Even the handling of the manual parts of merging renamed/moved files could be done in the client and/or front-end. There's not even any need to do anything fancy -- just search back for magic rename comments in files that had no changes merged and if they are the result of a rename then go look (recursively) for the ancestor revision in the old file(s) and manually do the merge on the client side. Nothing at all needs to be changed in the repository structure to support such functionality. If people really want it then _they_ should build it! CVS is user supported software! How 'bout: Your company decides to change its name or goes through a merger and you're programming in Java? I'd say that people using CVS for Java (at least with traditional java development environments) are already on the verge of being in the land of the truly unsupported anyway. In any case, /why/ would it matter why anyone would do this? The fact is that it's a request commonly made. Your answer seems to be to deem that request as being wrong. People make stupid and idiotic requests of all kinds of things all the time. Only marketing departments ever seem to see any need to satisfy them. There's nothing wrong with telling someone that their request is wrong/inappropriate/out-of-place if that's the case. I thought most of us in the software world were supposed to be more in tune with doing careful requirements analysis and such. In the end, every product is market-driven -- if there's no need for CVS, it wouldn't exist. Sorry, I should have qualified that as mass-market (though I did qualify CVS as niche market). I think Greg has been saying that CVS is a niche product and that it shouldn't braoden it's horizons. So, if: 1. You have binary files, 2. You _ever_ need to rename files for the lifetime of your project, 3. You want to version directories, 4. You want to reuse a filename that's been rm'd in the past but with a different type, 5. Possibly others I can't think of right now, then don't use CVS. Well, not exactly 100% on all those points, but within reason. In this forum 99.999% of the FAQs that have no existing answer in context are from people who should not be using CVS in the first place (or who can't find anything better and are then uwilling to figure out how to use CVS properly). In fact there's obviously a very strong demand for something to fill the niche that CVS fits well into The only problem is that at least half the people in the world who are not in that niche seem to think that they should be able to use CVS for whatever hair-brained idea they've got too. If someone wants a tool with broader horizons than CVS then they should build it (and call it something else, of course ;-). If it eventually replaces CVS entirely then that's OK. If it doesn't then those in the niche where CVS fits will still have an appropriate tool to use to meet their needs. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: BRANCH LABEL FOR DIRECTORIES
So now you're saying that it could be included OOTB AND that you've proposed it in the past. But you've been arguing that this is a BAD IDEA (TM) and seem to continue that position later in the same e-mail! I'm just sitting on the sideline and observing this one, but you seem to be trying to have your cake and eat it! *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Tuesday, 19 June 2001 9:04 a.m. To: CVS-II Discussion Mailing List Subject: Re: BRANCH LABEL FOR DIRECTORIES [ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ] Subject: Re: BRANCH LABEL FOR DIRECTORIES So why not have CVS do this work OOTB? You could. It's been proposed several times before. Nobody's stepped up to write the code. Even though I've also proposed it in the past, my proposal was in response to someone else's problem and of late I've not even had time to implement the solutions to my own problems, let alone anyone else's! ;-) It should be quite trivial to add such rename functionality to any of the more advanced font-ends to CVS (be they either stand alone clients, or wrappers that just call the existing command-line client). Even the handling of the manual parts of merging renamed/moved files could be done in the client and/or front-end. There's not even any need to do anything fancy -- just search back for magic rename comments in files that had no changes merged and if they are the result of a rename then go look (recursively) for the ancestor revision in the old file(s) and manually do the merge on the client side. Nothing at all needs to be changed in the repository structure to support such functionality. If people really want it then _they_ should build it! CVS is user supported software! How 'bout: Your company decides to change its name or goes through a merger and you're programming in Java? I'd say that people using CVS for Java (at least with traditional java development environments) are already on the verge of being in the land of the truly unsupported anyway. In any case, /why/ would it matter why anyone would do this? The fact is that it's a request commonly made. Your answer seems to be to deem that request as being wrong. People make stupid and idiotic requests of all kinds of things all the time. Only marketing departments ever seem to see any need to satisfy them. There's nothing wrong with telling someone that their request is wrong/inappropriate/out-of-place if that's the case. I thought most of us in the software world were supposed to be more in tune with doing careful requirements analysis and such. In the end, every product is market-driven -- if there's no need for CVS, it wouldn't exist. Sorry, I should have qualified that as mass-market (though I did qualify CVS as niche market). I think Greg has been saying that CVS is a niche product and that it shouldn't braoden it's horizons. So, if: 1. You have binary files, 2. You _ever_ need to rename files for the lifetime of your project, 3. You want to version directories, 4. You want to reuse a filename that's been rm'd in the past but with a different type, 5. Possibly others I can't think of right now, then don't use CVS. Well, not exactly 100% on all those points, but within reason. In this forum 99.999% of the FAQs that have no existing answer in context are from people who should not be using CVS in the first place (or who can't find anything better and are then uwilling to figure out how to use CVS properly). In fact there's obviously a very strong demand for something to fill the niche that CVS fits well into The only problem is that at least half the people in the world who are not in that niche seem to think that they should be able to use CVS for whatever hair-brained idea they've got too. If someone wants a tool with broader horizons than CVS then they should build it (and call it something else, of course ;-). If it eventually replaces CVS entirely then that's OK. If it doesn't then those in the niche where CVS fits will still have an appropriate tool to use to meet their needs. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED
RE: BRANCH LABEL FOR DIRECTORIES
[ On Tuesday, June 19, 2001 at 11:42:20 (+1200), Chris Cameron wrote: ] Subject: RE: BRANCH LABEL FOR DIRECTORIES So now you're saying that it could be included OOTB AND that you've proposed it in the past. But you've been arguing that this is a BAD IDEA (TM) and seem to continue that position later in the same e-mail! No, I did not argue that it was a bad idea. I said that it was not a necessary feature of a basic source code control system like CVS. What I and others have proposed are methodologies to work within the existing feature set of CVS. I also said such a feature could be included out-of-the-box if someone would step up and write the code (test it, document it, etc.). What I did not say was how it might come out of the box -- it could just as easily take the form of a little set of shell scripts to be used as command-line wrappers. I'm just sitting on the sideline and observing this one, but you seem to be trying to have your cake and eat it! Ah, but in this case I can. Everything I've described about tracking the renaming/moving of files using cvs rm and cvs add with magically meaningful comment strings can be easily automated by a front-end. No change is necessary in CVS itself to achieve this functionality, therefore it is provably not a necessary feature of the basic CVS functionality. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
Alex Flores writes: In CVS, does a directory have versions as well or do only the files have versions. Only the files. -Larry Jones My life needs a rewind/erase button. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs