Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Saturday, October 13, 2001 at 12:34:03 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Greg A. Woods wrote: [ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. Huh??? RCS and CVS can read the files (correctly, and modify them, correctly), and humans aren't supposed to touch the repository directly anyway. And if humans know enough about the RCS file format, they know how to identify newphrases. And the introduced newphrases will be documented, so humans who happen to read the files will still understand them. Obviously you haven't thought through the long term consequences of doing something like that, especially in face of a potentially very wide diversity of how people might access a CVS repository. Hiding such information inside the RCS file in a non-standard extension, i.e. in a way that would make it invisible to standard RCS, or CVS, is not a good idea for a generic solution. Assuming that some kind of rename capability is built into CVS that stores additional metadata in the repository, then THAT version of CVS would become the standard. And presumably, the new standard CVS would also provide a means to at least examine and perhaps modify the new metadata. Unless a single shop uses multiple versions of CVS at once, there won't be any consistency problems with regard to the use of the new metadata. As for RCS, who cares? CVS users aren't supposed to have direct access to the repository anyway. And if for some reason someone really does need to read the contents of the CVS repository using RCS, perhaps as a means to converting to something else, who cares? RCS can still process the stuff it knows about. Whatever process lives outside of RCS will be ignorant about the new metadata and won't use it anyway. (If someone uses RCS to modify the repository, then it's certainly possible to get the new metadata wrong. But again, who cares? CVS repositories should be modified only by CVS anyway.) --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Sunday, October 14, 2001 at 01:49:56 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Assuming that some kind of rename capability is built into CVS that stores additional metadata in the repository, then THAT version of CVS would become the standard. And presumably, the new standard CVS would also provide a means to at least examine and perhaps modify the new metadata. That's not how the real world works, and you should know that by now. Unless a single shop uses multiple versions of CVS at once, there won't be any consistency problems with regard to the use of the new metadata. consistency problems aren`t the issue here, though of course if there's any bug in the current CVS that would cause it to trip over the extended non-standard metadata then such issues would instantly arise. As for RCS, who cares? Excuse me? Everyone _should_ care, and I for one certainly care an incredible amount. I was only placated into accepting the integration of RCS management inernally to CVS because it meant there could be an incredible boost of performance in some circumstances (eg. those where multiple external operations were previously required). I still worry about the differences in implementation and the supposedly innocuous differences in resulting RCS file contents. If I'd had the time I would have contributed code and tests to ensure that CVS produced ,v files indistinuishable in every way from those produced by doing the same operations with plain RCS. Maybe someday someone will still get around to doing this. The fact that CVS is simply a wrapper for RCS (even if only conceptually now) is one of its major features! (and it's not just because you can move RCS projects easily into CVS -- but also the other way around, and not just back to plain RCS, but to other tools that might use RCS as an underlying repository structure) CVS users aren't supposed to have direct access to the repository anyway. Well, it depends, but that's not really the issue. And if for some reason someone really does need to read the contents of the CVS repository using RCS, perhaps as a means to converting to something else, who cares? Anyone with any long-term investment in CVS _should_ care. RCS can still process the stuff it knows about. Of course -- that's the problem because the new, and in this case incredibly important, metadata is effectively hidden from its view. Whatever process lives outside of RCS will be ignorant about the new metadata and won't use it anyway. Of course -- and that wouldn't be as big a problem if it didn't affect the fundamental structure of the repository. (or perhaps you don't care about the renamed files when you go to recover your CVS repo and/or convert it to some other format?) yes CVS won't go away or be unusable in the same way that could happen to commercial software, but that doesn't change the fact that RC (If someone uses RCS to modify the repository, then it's certainly possible to get the new metadata wrong. But again, who cares? CVS repositories should be modified only by CVS anyway.) That's where you're going wrong in your thinking here I think. Yes during production CVS repositories should only be modified by CVS. However that's not the only concern of anyone with an investment in a CVS repository. -- 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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from Greg Woods: [ On Sunday, October 14, 2001 at 01:49:56 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Assuming that some kind of rename capability is built into CVS that stores additional metadata in the repository, then THAT version of CVS would become the standard. And presumably, the new standard CVS would also provide a means to at least examine and perhaps modify the new metadata. That's not how the real world works, and you should know that by now. Which part? The part that each shop adopts one version of its tools at a time (and that that version is fairly up to date), or the part that tools provide access to their meta-data? Everyone I know goes to great effort to use just one (recent) version of the tools that provide their process infrastructure. The tools usually provide some kind of access to examine their data, and the good ones provide admin functions to modify them, usually in the name of error recovery after corruptions. This does not necessarily mean that the format of the file is published, only that the data can be read and modified in a correct and coherent way. As for RCS, who cares? Excuse me? Everyone _should_ care, and I for one certainly care an incredible amount. I was only placated into accepting the integration of RCS management inernally to CVS because it meant there could be an incredible boost of performance in some circumstances (eg. those where multiple external operations were previously required). I still worry about the differences in implementation and the supposedly innocuous differences in resulting RCS file contents. If I'd had the time I would have contributed code and tests to ensure that CVS produced ,v files indistinuishable in every way from those produced by doing the same operations with plain RCS. Maybe someday someone will still get around to doing this. Why are you so concerned about CVS internal format? Do you do stuff to the repository outside of CVS? If you do, then shame on you; best practice is to use CVS' interfaces exclusively. The fact that CVS is simply a wrapper for RCS (even if only conceptually now) is one of its major features! The fact that CVS used RCS is an artifact of its implementation. At the time that CVS was designed, the authors needed a tool that did text deltas, and RCS was the only one freely available at the time that was stable enough to use. CVS continues to use the RCS file format to keep itself compatible with existing repositories. And there is precedent for adding new metadata; CVS did not always track dead versions, and the fact that the version state attribute is used now has the possibility of causing grief in cases where the RCS files are maintained by two different systems. (and it's not just because you can move RCS projects easily into CVS -- but also the other way around, and not just back to plain RCS, but to other tools that might use RCS as an underlying repository structure) Even if some new metadata are adopted, both transfers will continue to work as well as they do today. The ,v files copied into a CVS repository will still be compatible with CVS. The fact that the pointers that implement a rename capability will be absent just means that no renames have been done. As for going the other way, tools that read RCS files will still have the same data they get today. They'll also get more that they won't know what to do with. If they were implemented according to the RCS standard then they should ignore the CVS metadata, or perhaps set some kind of attribute and carry it in without interpretation. If the tool breaks, then report it as a bug or write a filter to remove the CVS meta-data. And if for some reason someone really does need to read the contents of the CVS repository using RCS, perhaps as a means to converting to something else, who cares? Anyone with any long-term investment in CVS _should_ care. If CVS provides interfaces to all of the metadata it uses that are stored in the RCS files, and users do not have direct access to the CVS repository, then why would they care that the repository is in RCS format? It's just an implementation detail that's hidden from them. (Well, cvs status hints at RCS files that are somehow related to the sandbox, but again the user has no access to it anyway.) RCS can still process the stuff it knows about. Of course -- that's the problem because the new, and in this case incredibly important, metadata is effectively hidden from its view. It's only important for features that fall outside of RCS' pervue. RCS still operates just fine on what it understands. If the new metadata are important to you, then use the tool that manages it: CVS. Whatever process lives outside of RCS will be ignorant about the new metadata and won't use it anyway. Of course -- and that wouldn't be as big a problem if it didn't affect the fundamental structure of the repository. (or
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Saturday, October 13, 2001 at 01:23:14 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] The problem is, I wouldn't hold my breath. You'll certainly turn blue if you try. CVS cannot easily ever support renaming to any extent that something like BitKeeper or Perforce does, at least not without breaking backwards compatabilty of the repository structure. There's simply no place to put the extra meta data necessary except in the commit comments themselves, and you can much more easily build simple little wrapper scripts to do renaming and to drive cvs log, cvs diff, cvs annotate, and cvs update if that's all you're going to do. I've already started the ball rolling, yet again, by posting yet another version of the first such wrapper needed. You're working on this too? I'm going through the design stages of a full blown CVS front end called Meta CVS. The idea is that all you store in CVS is a flat database of files that have completely cryptic, machine-generated names. Along with that, you store a mapping which assigns path names to these objects. On checkout, Meta CVS obtains a sandbox, and then processes the mapping file to create the tree. When you do updates, Meta CVS calculates the difference between the old mapping file and the new (after the user resolves any conflicts) and then rearranges your tree accordingly. If you want to move something, you do it thorugh Meta CVS. It updates its working copy of the mapping file and performs the move. You can then commit to ``make it so''. If the up-to-date check fails on the mapping file, you update, and resolve the conflict. Meta CVS will then move local files around as necessary to reflect your resolution, always keeping a prior version of the mapping file stashed somewhere to determine what rearrangements must be done. I'm thinking of also post-filtering the output of certain cvs commands like rdiff and log. For example, the output of rdiff could be edited to replace the machine-generated names with the mapped pathnames. Not only that, but a POSIX shell script could be prepended or appended to the output, containing mv commands. The idea is that someone with an old version of a tree could execute the renaming script, and then apply the rest of the patch to get to the new version of the tree. Thereby the powers of patch would be effectively extended to doing renaming and directory reshaping. Another idea I have is to implement a whole new tagging system. The project contains a special tag file. When you create a tag with Meta CVS, it adds an entry into the tag file and commits. The entry contains the tag name, and a list of files and their versions. So instead of rewriting every darn tagged file, the baseline information is recorded in one place, so tagging is much cheaper. Moreover, the tag store is itself versioned, so you know when the tag was created and can attach a comment to a tag creation or deletion. Meta CVS can checkout or update to a selected tag by individually pulling out the right revision of each file; an optional patch can be provided for CVS to make this expressible in a single CVS command. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Saturday, October 13, 2001 at 06:16:25 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: There's simply no place to put the extra meta data necessary except in the commit comments themselves, and you can much more easily build simple little wrapper scripts to do renaming and to drive cvs log, cvs diff, cvs annotate, and cvs update if that's all you're going to do. I've already started the ball rolling, yet again, by posting yet another version of the first such wrapper needed. You're working on this too? No, it's just more or less the same script I've posted a half dozen times in the past every time this issue comes to a head. Others have posted similar scripts in the past too. :-) I'm going through the design stages of a full blown CVS front end called Meta CVS. The idea is that all you store in CVS is a flat database of files that have completely cryptic, machine-generated names. Along with that, you store a mapping which assigns path names to these objects. I alread use a CVS front-end almost exclusively: PCL-CVS. I haven't bothered working on any rename support for it though. Another idea I have is to implement a whole new tagging system. The project contains a special tag file. When you create a tag with Meta CVS, it adds an entry into the tag file and commits. The entry contains the tag name, and a list of files and their versions. So instead of rewriting every darn tagged file, the baseline information is recorded in one place, so tagging is much cheaper. There are a number of very good reasons for paying the price of modifying every file when tagging. You do not want to stray to far from being compatible with plain CVS, or plain RCS for that matter. -- 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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. Huh??? RCS and CVS can read the files (correctly, and modify them, correctly), and humans aren't supposed to touch the repository directly anyway. And if humans know enough about the RCS file format, they know how to identify newphrases. And the introduced newphrases will be documented, so humans who happen to read the files will still understand them. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Saturday, October 13, 2001 at 12:34:03 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Greg A. Woods wrote: [ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. Huh??? RCS and CVS can read the files (correctly, and modify them, correctly), and humans aren't supposed to touch the repository directly anyway. And if humans know enough about the RCS file format, they know how to identify newphrases. And the introduced newphrases will be documented, so humans who happen to read the files will still understand them. Obviously you haven't thought through the long term consequences of doing something like that, especially in face of a potentially very wide diversity of how people might access a CVS repository. Hiding such information inside the RCS file in a non-standard extension, i.e. in a way that would make it invisible to standard RCS, or CVS, is not a good idea for a generic solution. -- 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: [kfogel@collab.net: Re: rename in cvs]
* In message 6npx7.65227$[EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 22:50:42 GMT * Honorable [EMAIL PROTECTED] (Kaz Kylheku) writes: why can't cvs mv just rename the *,v file? Because then if you check out (or export) an old tagged build of the software, it will have the rename. And that will very likely break the old build. A fundamental principle of version control is that when you label some release of the software, it is fixed for posterity. Anyone can go back and retrieve that release exactly. This capability essential if you ever need to go back to that version and shoot off a bugfix branch, for instance. In CVS, you can no longer do this if you start moving around the *,v files. If you can't go back to tagged builds, then your version control system is reduced to a mere piece of collaboration ``groupware'' at best, and a file backup system at worst. ;) Oh my!!! Finally!!! Yess!!! Thanks!!! Now I see the light. I wonder why Greg A. Woods could no say that as a reply to the _first_ message suggesting this. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ We're too busy mopping the floor to turn off the faucet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 23:08:38 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] I gain the requirement of having to type multiple cvs log or cvs rlog commands, after figuring out every place a file has lived during its lifetime. I gain the requirement of carefully scrutinizing the output of each of those commands to determine which revisions contributed to my working copy. Hmmm... yes, you gain the requirement of having to understand a little bit about what you're doing -- there is no autopilot (unless someone writes more little wrapper scripts like the one I posted). -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 12, 2001 at 10:59:41 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] I wonder why Greg A. Woods could no say that as a reply to the _first_ message suggesting this. Because you could have figured this out with only the tiniest amount of research on your own, including just reading the fine CVS manual itself. I made the fatal assumption that you had already read the manual and were instead just being a bully about wanting a feature. -- 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: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Fri, 12 Oct 2001 13:04:14 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 12, 2001 at 10:59:41 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] I wonder why Greg A. Woods could no say that as a reply to the _first_ message suggesting this. Because you could have figured this out with only the tiniest amount of research on your own, including just reading the fine CVS manual itself. the explanations are recent additions - they weren't there when I read the manual (a year ago?). Also, the manual does _not_ explain why cvs cannot do what is described in http://www.cvshome.org/docs/manual/cvs_7.html#SEC72 with cvs mv and http://www.cvshome.org/docs/manual/cvs_7.html#SEC73 with cvs cp. especially the last one which has only one disadvantage -- * You cannot easily see the history of the file across the rename. whose meaning I don't understand. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ I want Tamagochi! -- What for? Your pet hamster is still alive! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, October 11, 2001 at 23:08:38 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] I gain the requirement of having to type multiple cvs log or cvs rlog commands, after figuring out every place a file has lived during its lifetime. I gain the requirement of carefully scrutinizing the output of each of those commands to determine which revisions contributed to my working copy. Hmmm... yes, you gain the requirement of having to understand a little bit about what you're doing -- there is no autopilot (unless someone writes more little wrapper scripts like the one I posted). I understand perfectly what I am doing. I may not understand perfectly what someone else is doing with that old path. And I may not understand perfectly what my predecessor did with my file in its distant past. If I did, I would not be seeking out its history, now would I? In any case, your wrapper script is insufficient; it doesn't display my file's entire history without the cruft of a second (or third or fourth) that happen to have shared a path with my file at some point. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, October 11, 2001 at 23:12:44 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] --- Forwarded mail from Greg Woods: Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! You do, if the version history of FOO is part of the history of BAR, having become that way by way of a reorganization of the project. No, it's not. That's a figment of your imagination -- not the reality of what CVS is doing. You are right. But I think the point we're trying to make is that CVS is doing the wrong thing, i.e. it is broken. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, October 11, 2001 at 23:12:44 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] --- Forwarded mail from Greg Woods: Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! You do, if the version history of FOO is part of the history of BAR, having become that way by way of a reorganization of the project. No, it's not. That's a figment of your imagination -- not the reality of what CVS is doing. You are right. But I think the point we're trying to make is that CVS is doing the wrong thing, i.e. it is broken. Not really. CVS does not support renaming. In that sense, its version management is incomplete. Let's not confuse incompleteness with incorrectness. Deleting a file and making a new one with the same contents is something other than renaming. It's not broken renaming. It only looks broken when we call it renaming; calling it renaming doesn't make it renaming. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Friday, October 12, 2001 at 21:07:09 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Not really. CVS does not support renaming. In that sense, its version management is incomplete. Let's not confuse incompleteness with incorrectness. Deleting a file and making a new one with the same contents is something other than renaming. It's not broken renaming. It only looks broken when we call it renaming; calling it renaming doesn't make it renaming. well said! Thank you! -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 12, 2001 at 13:51:10 (-0400), Sam Steingold wrote: ]
Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
Also, the manual does _not_ explain why cvs cannot do what is described
in http://www.cvshome.org/docs/manual/cvs_7.html#SEC72 with cvs mv
and http://www.cvshome.org/docs/manual/cvs_7.html#SEC73 with cvs cp.
Well, the Moving the History file method really should not be
documented in the first place. It is a very seriously dangerous hack
that even knowlegable people should not attempt (it's way too easy to
make mistakes). I think the only reason it got into the manual was
because so many people naively tried it and then whined about the
resulting problems that documenting its problems up front was the best
way to convince people to not do it.
As for why CVS doesn't internally implement either of the latter two
schemes, well the reasons should be obvious. The former is simply far
too dangerous and can cause major damage to a repository -- damage
that's impossible to undo without having a trace of the commands that
caused it. The latter is extremely tricky to get right too, and
impossible to do automatically in some scenarios; and given the
additional disadvantages I outline below it's questionable as to whether
it should even be documented.
especially the last one which has only one disadvantage --
* You cannot easily see the history of the file across the rename.
whose meaning I don't understand.
That's a pretty major disadvantage in the larger scheme of things. You
cannot any longer discover that the file was renamed just by looking at
it or at its history. (Actually there is a trick that helps, but I'm
going to be nasty and not tell you what it is! ;-)
There are also other very serious disadvantages that the released manual
does not explicitly list:
@item
This method fails in drastic but hidden ways if
@var{new} ever existed previously and had been
subsequently removed.
@item
This method fails utterly for files with branches.
@item
This method requires direct access to the repository.
@item
You cannot use @samp{-D@var{date}} to safely retrieve
previous revisions.
Of course there are some large projects which have decided to go about
doing renames using this policy regarless (eg. NetBSD).
--
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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] In article [EMAIL PROTECTED], Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, October 11, 2001 at 23:12:44 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] --- Forwarded mail from Greg Woods: Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! You do, if the version history of FOO is part of the history of BAR, having become that way by way of a reorganization of the project. No, it's not. That's a figment of your imagination -- not the reality of what CVS is doing. You are right. But I think the point we're trying to make is that CVS is doing the wrong thing, i.e. it is broken. Not really. CVS does not support renaming. In that sense, its version management is incomplete. Let's not confuse incompleteness with incorrectness. Deleting a file and making a new one with the same contents is something other than renaming. It's not broken renaming. It only looks broken when we call it renaming; calling it renaming doesn't make it renaming. Fine. CVS doesn't support renaming. We all know that. So it's incomplete. Some would still claim that its lack of support for renaming means that CVS is broken and needs to be fixed. That is to say, it's BAD (Broken As Designed) and that the fix must be made at a very fundamental level. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Paul Sander wrote: It only looks broken when we call it renaming; calling it renaming doesn't make it renaming. Fine. CVS doesn't support renaming. We all know that. So it's incomplete. Some would still claim that its lack of support for renaming means that CVS is broken and needs to be fixed. That is to say, it's BAD (Broken As Designed) and that the fix must be made at a very fundamental level. The problem is, I wouldn't hold my breath. You will likely see Subversion mature into production use, yet CVS won't yet support renaming at that time. At which point it will become moot. CVS would likely require a massive rewrite to get the repository support for renaming. In a sense, Subversion *is* that massive rewrite. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Saturday, October 13, 2001 at 01:23:14 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] The problem is, I wouldn't hold my breath. You'll certainly turn blue if you try. CVS cannot easily ever support renaming to any extent that something like BitKeeper or Perforce does, at least not without breaking backwards compatabilty of the repository structure. There's simply no place to put the extra meta data necessary except in the commit comments themselves, and you can much more easily build simple little wrapper scripts to do renaming and to drive cvs log, cvs diff, cvs annotate, and cvs update if that's all you're going to do. I've already started the ball rolling, yet again, by posting yet another version of the first such wrapper needed. -- 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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] CVS cannot easily ever support renaming to any extent that something like BitKeeper or Perforce does, at least not without breaking backwards compatabilty of the repository structure. There's simply no place to put the extra meta data necessary except in the commit comments themselves, They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. -- 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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, October 10, 2001 at 14:40:11 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In one method, you lose the ability to get a file's entire revision history in one place (i.e. you must track down its old location(s) and fetch additional history from there). That's not a loss, nothing is lost -- that a stupid illogical complaint. And not only do you lose the ability to get a file's entire version history with a single cvs log, you also have added to a file's revision history all of the unwanted stuff from a previous incarnation that was renamed away. Defending the ambiguity of the histories of logically different files that happen to share a path at one time or another, and the fragmentation of a file's entire version history is nonsensical. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] if you rename FOO to BAR the right way, i.e., $ mv FOO BAR $ cvs rm FOO $ cvs add BAR $ cvs ci BAR then you lose in many ways: No, you lose absolutely nothing -- in fact you _gain_ the information about the rename! This is only true if the user performing the steps above remembers to include a comment. The other thing is that because the rename isn't atomic, it can be only partially completed and cause problems for other developers caught up in the race condition. A usable rename would have the following user model and store the fact of the rename automatically: cvs mv FOO BAR cvs ci BAR The mv would move the working copy and update the CVS sandbox state as needed, ideally recording the fact of the move there to be stored at commit time. It would also have to be robust enough to be repeatable (i.e. cvs mv FOO BAR; cvs mv BAR BAZ; cvs commit BAZ) and reversible (i.e. cvs mv FOO BAR; cvs mv BAR FOO; cvs commit FOO) before the commit. The commit would (in a single transaction) deaden the appropriate version of FOO, create BAR (or resurrect it), create the appropriate tags (if the sandbox is on a branch), and commit local changes. But again, there are the fragmented history and ambiguous history problems. * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. It's totally logical if BAR and FOO are the same file, BAR having been renamed to FOO. Remember, the version histories of BAR and FOO are only fragments of the file's entire version history. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. Not with the cvs diff command, it isn't (assuming BAR was renamed to FOO). You must have both files checked out somewhere (and one usually isn't) before the standard diff program will work. -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. The first point was: etc - CVS does not know that FOO is the old name for BAR. That's the important part. Fragmented version histories are a royal pain. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 01:03:59 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. why? this is the same file. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. okay. I _really_ do need this, and I will greatly appreciate an instruction on how to do this. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these revisions, sequentially, first those from compiler.lsp,v, then from compiler.lisp,v. The only thing I can think of is: check out compiler.lsp and patch it, one by one, with all the patches that went into compiler.lisp, then go (using shell) into the CVS repository and rename compiler.lsp,v to compiler.lisp,v. The problem is that there are 64 such files, so this process will have to be automated somehow. BTW, is there any difference, from the CVS POV, between $ cvs ci -m mesg FOO BAR and $ cvs ci -m mesg FOO $ cvs ci -m mesg BAR ? the reason I am asking is that some files have been checked in together, so I will need to do some trickery to check the diffs into the old names together too. The problem is that I do not always have shell access - then I am stuck. You don't need to have shell-level access to the repository. this is very nice to hear. could you please tell me what to do? I hope I made my needs quite clear already. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ The program isn't debugged until the last user is dead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 01:59:20 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] And not only do you lose the ability to get a file's entire version history with a single cvs log, That is not a loss -- it is a gain. You have it backwards. you also have added to a file's revision history all of the unwanted stuff from a previous incarnation that was renamed away. Well, yes, that's a bit of a bug, but we've discussed the obvious and very easy solution several times in the past Defending the ambiguity of the histories of logically different files that happen to share a path at one time or another, and the fragmentation of a file's entire version history is nonsensical. Since you've never really understood how CVS manages change and how filenames are used within CVS, this strange is not unsurprising. -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. You are not properly understanding how CVS uses filenames and how it manages change to those files. CVS tracks changes to the contents of files by using their filenames as anchors in the directory structure. It knows nothing of what's in the files though, nor of their relationship to each other (except of course for their names and their hierarchical position in an underlying directory structure). It does this by effectively taking snapshots of the contents of the files and storing them in RCS files in the repository. The repository directory structure is laid out exactly as the working directory's structure is so as to make all of its operations one-to-one on each file in a module (with the exception of some optimisations it uses in the repository to avoid wasting time on dead files). If you take away a file then CVS marks it as dead and stops copying its old contents to working directories. If you add a file CVS starts tracking changes to that file (again if it was previously dead). There is no concept of a rename because CVS does not try to intuit that a newly added file's contents look a lot like some other removed file's contents. Just as in any simple relational database there is only an add and a delete operation and change is expressed through a combination of these operations. If you wish to remember that you've moved the contents of one file to another file then you need to do this in the same way you remember any other change -- i.e. with a commit comment. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. Hmmm that's a very outrageous example of an idiotic change with no productive end result. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! CVS is simply not designed to manage such large-scale renames. They are far beyond the design goals of a simple file handling tool like CVS. The most obvious logical approach to renaming those files would have been to add another intermediate step to your build process to do the rename at build time. The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. No change control tool, especially none which has zero understanding of the semantics of the files it manages, can cope in either of these examples. In other words for the example you describe the result is illogical from the very beginning -- to ask for CVS to now treat two different files as one is therefore equally illogical. Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. That way you are not tempted to do things that would be illogical in the first place. The same is true with SCCS and RCS, and no doubt with TCCS, PRCS, Aegis, Perforce, and other similar tools too. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? CVS is not a programming language. Do we have to add that to the manual too?!?!?! Why is it that people are often blinded to the obvious when they are given a tool that combines many operations but not all operations? Perhaps everyone should do without RCS and without CVS for some small project and track every change to every file manually for a time. Then you would not so easily forget how to do such things when you use CVS! -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. okay. I _really_ do need this, and I will greatly appreciate an instruction on how to do this. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. You should accept that some people do not form a religious belief system around the capabilities of a software system. Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. Really? So until you wholeheartedly accept the limitations of a system the point that you can't imagine or want anything else, you can't understand that system? I believe that you only need to undersatnd and accept the limitations in order to properly *use* the system in the way it was designed. There is no need to accept those limitations for any other purpose, religious or whatever. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. yes, actually it is. you want me to look at the world through the tool-imposed blinders. no way. these files are the same, period. the issue is that CVS does not recognize that. Actually, now that the damage (i.e., the right way - cvs add/rm) has been done, CVS really has no reason to recognize the truth and admit that the files are the same. But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. CVS tracks changes ... thanks for repeating this. actually, I knew all this, but it was nice to here that my knowledge was correct. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. Hmmm that's a very outrageous example of an idiotic change with no productive end result. you do not have to be rude. you do not know all the circumstances. I was not the one who did it. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! CVS is simply not designed to manage such large-scale renames. They are far beyond the design goals of a simple file handling tool like CVS. why? why can't cvs mv rename the *,v file? The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! That way you are not tempted to do things that would be illogical in the first place. The same is true with SCCS and RCS, and no doubt with TCCS, PRCS, Aegis, Perforce, and other similar tools too. Okay. I have never used TCCS, PRCS, Aegis, Perforce and SCCS. Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. MS SourceSafe also can rename a file. Thus, of all the tools accessible to me, only CVS refuses to rename files. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO Let me repeat again: file renaming is a reasonable operation and it must be supported in a reasonable way. Just like cp+rm is not a reasonable replacement for mv, cvs add/rm is not a reasonable replacement for cvs mv. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these revisions, sequentially, first those from compiler.lsp,v, then from compiler.lisp,v. I think you are asking the wrong question. You have not stated the base requirement which seems to be driving your desire to do this. I want to be able to see the change history for compiler.lisp c. If your goal is simply to forget that you ever had *.lsp files then obviously it would have been easier to simply rename them in the repository. yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. The best process for your situation depends on many factors you have not described to us, such as whether or not you have other active branches, and whether or not you have previous releases that must be retained, and also whether or not you have renamed any other files in the past too. there are no branches, but there are many tags
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. It's only not the same file because of the braindamaged version control system which cannot represent that semantic idea! As far as the user is concerned, it is the same file, under a different name. Merely, the software has failed to capture the user's perfectly sensible idea. Instead, it provided a half-baked emulation: delete the old, recreate under new name. This breaks seriously, for instance, under merging. Suppose work takes place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is created with identical contents, in order to emulate a rename. When the branch is later merged, the FOO patches will not be applied to BAR. Moving the patches to BAR will require error-prone manual work. This should be pereceived as enough of a problem to completely deter clueful users form trying to rename files. The best way to view CVS is that it does not handle renames at all, so don't even think about ever doing it using *any* of the methods recommended in the manual. I can live without being able to view the complete history of the object in one piece. But the other breakage, in particular merging, makes it totally unacceptable to do a rename. I accept the limitation only because CVS has open source code, a suitable redistribution license, good reliability and a set of capabilities that is good enough for many purposes. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Sam Steingold wrote: * In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. yes, actually it is. you want me to look at the world through the tool-imposed blinders. In fact I have the same impression. It consistently *appears* as if Greg wants people to accept the limitations of CVS to an irrational degree. In his view, it appears, I must not only accept that CVS doesn't handle renames, but also stop wanting a version control system that handles renames. In fact, I must stop seeing file renames as legitimate version control events. Otherwise, presumably, my mind will somehow go to pieces imagining something that the selected tool doesn't provide. This may be far from the intent, but it sure reads that way, Greg! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 19:15:30 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. Are we talking about CVS, or some fictional tool here? I'm talking about CVS. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. Ah, so you're not talking about CVS -- why are you posting here then? -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 19:51:13 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's only not the same file because of the braindamaged version control system which cannot represent that semantic idea! As far as the user is concerned, it is the same file, under a different name. Merely, the software has failed to capture the user's perfectly sensible idea. Instead, it provided a half-baked emulation: delete the old, recreate under new name. I think you have extremely unrealistic expectations. I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. This breaks seriously, for instance, under merging. Suppose work takes place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is created with identical contents, in order to emulate a rename. When the branch is later merged, the FOO patches will not be applied to BAR. Indeed -- you've spotted one of the many limitations of CVS. While it likes to do merging, a lot, it doesn't always know when to do merges and it cannot be relied upon to do all merges and to always do them correctly. The programmer is still ultimately responsible for all merges. Moving the patches to BAR will require error-prone manual work. Merging is always potentially error prone. Manual merging is often almost ininitely _LESS_ error prone than automated merging. Why the heck do you think some people oppose CVS so much? It's primarily because they don't trust automated merging It is certainly not a bad thing that CVS forces you do to some manual merging. It might be nice if it could store more metadata to suggest to you when you have to do a manual merge, but it doesn't and so you must keep track yourself and verify that the results of all merges include all of the changes you intend them to keep. This should be pereceived as enough of a problem to completely deter clueful users form trying to rename files. The best way to view CVS is that it does not handle renames at all, so don't even think about ever doing it using *any* of the methods recommended in the manual. Well, if you have lots of branches you want to avoid renames as much as possible, but it's not a dead-end un-penetrable brick wall -- a little bit of consiousness is all it takes to work around this limitation. The biggest trick is to learn to plan properly. If you do your renames at major milestone markers in your development process then you can likely eliminate most of the need to merge changes across the renames. This isn't rocket science -- it's really quite basic accounting. There's really nothing new about this limitation -- any tool more primitive than CVS would have similar limitations and any experience developer should know that big changes which have no semantic meaning must be planned carefully so that they don't obscure other changes. People did change management manually for decades. CVS can do much of the really mundane work, but it is not a complete change management system. I can live without being able to view the complete history of the object in one piece. But the other breakage, in particular merging, makes it totally unacceptable to do a rename. I think you've got big blinders on. If you expect one tool to suddendly do everything and totally eliminate any and all manual change management then you will likely never be satisified. Take your blinders off and learn to do some of the tasks the hard way -- it really isn't all that hard and so long as you don't do too many renames in places where merging will eventualy be necessary you won't have very much trouble managing your changes around renames. I accept the limitation only because CVS has open source code, a suitable redistribution license, good reliability and a set of capabilities that is good enough for many purposes. In the freeware markeplace there's always room for more tools! :-) -- 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: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:03:50 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! Could you please elaborate? _Why_ is it illogical? _Why_ is it unnecessary? Let me try to repeat: FOO and BAR here are the same file (like compiler.lisp and compiler.lsp). If FOO is renamed to BAR when it is at 1.125, then the change from FOO 1.123 to BAR 1.3 is a matter of 4 modifications: 1. FOO 1.123 -- FOO 1.124 2. FOO 1.124 -- FOO 1.125 == BAR 1.1 3. BAR 1.1 -- BAR 1.2 4. BAR 1.2 -- BAR 1.3 Why can't I see the log for all of them in one command? Consider a versioning file system which has a native idea of file version. I can rename file FOO;latest to BAR;latest, keeping the older versions of FOO named FOO;1, FOO;2 c. - this corresponds to the CVS method (rm/add). But I also can rename _all_ version of FOO to BAR. This _is_ a reasonable thing to do. Why can't I do it with CVS? Please note that the answers like this is not how CVS manages change! are not very convincing, because the natural retort is then maybe CVS manages change incorrectly? Please tell us _why_ the request for the CVS command mv, which would rename the *,v file and replace the CVS/Entries entry is unreasonable. (Oh yeah, CVSROOT/history should also be suitably modified and a record of the renaming to allow for undoing it should also be added. But is these are too hard to implement, forget it and stick with a simple mv FOO,v BAR,v). And while I am talking about undoing, why can't a revision be removed from the CVS? just like I can remove a revision in a versioning file system, I should be able to remove a revision from the CVS. Don't get me wrong. CVS is a great tool. Let's make it even better! -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ The paperless office will become a reality soon after the paperless toilet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 19:15:30 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. Are we talking about CVS, or some fictional tool here? I'm talking about CVS. Even if you are talking about CVS, you can still wish that it did something for you that it does not. Users of existing software tend to have requirements that are not met by that software, and which sometimes appear in new revisions. That is how progress takes place, in part. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. Ah, so you're not talking about CVS -- why are you posting here then? To counter your insulting claim that wishing for a hygienic renaming feature is illogical. Since that claim was posted here, my reply is posted here also. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You're not making sense. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. you do not have to be rude. I wasn't -- I was merely pointing out that such an example is not relevant to this discussion since it is far beyond what most any file-based change control tool can ever do. you do not know all the circumstances. I was not the one who did it. I didn't claim to know the circumstances, nor who did it -- that's all mostly irrelevant. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. Well, whether that would have been the right thing or not depends on several other factors. why? why can't cvs mv rename the *,v file? Nope -- no file-based change control tool can. You have to add a whole mess of meta-data on top, and the more you think about all the corner cases and side effects, the deeper the pile gets. Soon you end up building a system that's completely the opposite of a file-based change control tool -- i.e. one that constructs files out of sets of changes that are probably stored in a more sophisticated database than any unix-like filesystem can ever be on its own. The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. but the EFFECT (on the change management process) is the same!!! Unless you understand this you will fail to understand the larger issue here! Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! It all depends on many many many factors. In a simple and relatively straight forward project it works very well over extended periods of time. Take NetBSD or FreeBSD, or even the CVS-II source itself, for example Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. I think you don't understand the larger issues here. What vc-rename-file does breaks all kinds of things in the larger SCM picture! It is a cheap hack that wise people would only use in very limited circumstances. Thus, of all the tools accessible to me, only CVS refuses to rename files. CVS refuses to rename files because the CVS designers were aware of all the deeper issues and they didn't want to create a situation worse than the current alternative. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO well as a matter of fact the rename(2) call is a recent addition BUT, You're trying to compare totally unrelated things here -- it might look so simple on the surface, but when you have to keep track of such operations over time requires much more than a simple rename command! please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. Jump over your head? What kind of nonsense is that? The procedure is trivial! Why are you complaining about something so simple and obvious? Just do it! yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. be careful what you wish for -- you may only create a worse nightmare. If I were you I would break from the past and start fresh. -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 20:15:10 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In fact I have the same impression. It consistently *appears* as if Greg wants people to accept the limitations of CVS to an irrational degree. Well, if you don't want to accept it, what, EXACTLY, are you going to do about it? Do you have a viable alternative tool waiting in the wings? If so then why haven't you proposed it as an alternative? In his view, it appears, I must not only accept that CVS doesn't handle renames, but also stop wanting a version control system that handles renames. That's not what I said at all. In fact, I must stop seeing file renames as legitimate version control events. I certainly didn't say that either. CVS doesn't support renames, but it provides enough mechanism to make it relatively easy to manually track renames and to manually perform operations on renamed files that CVS itself can never do internally. Anything that can be done manually can, obviously, also be scripted. -- 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: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:08:07 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. As I said in another message, in Emacs, M-x vc-rename-file RET will work when the back-end is RCS or SCCS, but not when it is CVS. I have no idea what SCCS is, but I thought that RCS was _more_ primitive than CVS. All the problems you are talking about here (merging c) arise for one simple reason - you do not have cvs mv and you make people think that cvs add/rm has anything to do with renaming. There are two levels to renaming: * you can go the filesystem way, do mv(1) and forget the old name completely, * or you can go the change management: way, and remember the old name(s), permitting undo c. Not providing _either_ is brain damage. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ .sigs are like your face - rarely seen by you and uglier than you think ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:51:02 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. why? why? why can't cvs mv rename the *,v file? Nope -- no file-based change control tool can. You have to add a whole mess of meta-data on top, and the more you think about all the corner cases and side effects, the deeper the pile gets. Soon you end up building a system that's completely the opposite of a file-based change control tool -- i.e. one that constructs files out of sets of changes that are probably stored in a more sophisticated database than any unix-like filesystem can ever be on its own. why? why can't cvs mv just rename the *,v file? let me repeat: why can't cvs mv just rename the *,v file? The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. but the EFFECT (on the change management process) is the same!!! why? Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. I think you don't understand the larger issues here. What vc-rename-file does breaks all kinds of things in the larger SCM picture! It is a cheap hack that wise people would only use in very limited circumstances. I am not saying I will be doing cvs mv twice a day. I have felt the need for it about twice in my life. The fact that CVS cannot do it is still haunting me. Thus, of all the tools accessible to me, only CVS refuses to rename files. CVS refuses to rename files because the CVS designers were aware of all the deeper issues and they didn't want to create a situation worse than the current alternative. what can be worse?! cut the socialist crap. remember the 2nd amendment, give me the damned gun and explain me that I should be careful not to shoot myself -- but let _me_ decide what I want to do. Would you like to use a file system which lacked rename(2) syscall well as a matter of fact the rename(2) call is a recent addition so? BUT, You're trying to compare totally unrelated things here -- it might look so simple on the surface, but when you have to keep track of such operations over time requires much more than a simple rename command! okay - so don't keep track! just rename the darn *,v files! yes, rename then would be global - all branches will be affected. so issue a warning! those who can be hurt by this will not use this. yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. be careful what you wish for -- you may only create a worse nightmare. bull. I did a manual rename of *,v files in the CVS repository one. I have never had any problems with that. Everything works as expected. No problems. If I were you I would break from the past and start fresh. Don't be ridiculous. I have users to support. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ Live Lisp and prosper. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
%% Sam Steingold [EMAIL PROTECTED] writes: sam Could you please elaborate? It is pointless to argue about this. Many have tried before you, and if history is any judge you will accomplish nothing in the attempt. sam Don't get me wrong. CVS is a great tool. Let's make it even sam better! I've said many times here before: Subversion will be ready long before you could enhance CVS to get these features, even without the flak you're sure to take for even suggesting it. Subversion is already self-hosting and they're working hard towards the 1.0 release (and those guys _do_ work hard; they get a phenomenal amount of work done every week). If you want advanced capabilities like directory versioning, head over to Subversion and spend your time helping there. It's been made quite clear (to me) that CVS is Done. It does what it does, and if you want anything different you should get a different tool. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 20:15:10 (GMT), Kaz Kylheku wrote: ] In fact, I must stop seeing file renames as legitimate version control events. I certainly didn't say that either. That's great! I was hoping you'd be goaded into denying that you hold these extremist viewpoints, thereby clearing everything up. ;) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Sam Steingold wrote: * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. why? Because you would have to either change the representation of the repository, or implement a whole indirection layer over CVS so that the repository contains only ``anonymous'' objects which are assigned to locations in a sandbox tree through some auxiliary binding. why can't cvs mv just rename the *,v file? Because then if you check out (or export) an old tagged build of the software, it will have the rename. And that will very likely break the old build. A fundamental principle of version control is that when you label some release of the software, it is fixed for posterity. Anyone can go back and retrieve that release exactly. This capability essential if you ever need to go back to that version and shoot off a bugfix branch, for instance. In CVS, you can no longer do this if you start moving around the *,v files. If you can't go back to tagged builds, then your version control system is reduced to a mere piece of collaboration ``groupware'' at best, and a file backup system at worst. ;) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[EMAIL PROTECTED] (Kaz Kylheku) writes: In article [EMAIL PROTECTED], Greg A. Woods wrote: Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! It's irrational to want the present implementation of a tool to do something that it isn't designed to do. You should accept that some people do not form a religious belief system around the capabilities of a software system. It's irrational to want the present implementation of the other half of this dialogue to do something that it isn't designed to do. -- Mark Jackson - http://www.alumni.caltech.edu/~mjackson Meeting the author, I think, is one of life's most reliably disappointing experiences. - Billy Collins ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 21:33:05 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] To counter your insulting claim that wishing for a hygienic renaming feature is illogical. Since that claim was posted here, my reply is posted here also. Look if you want to discuss some mythical tool that you think should exist then why don't you go off to one of the forums more suited for that purpose? -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 17:55:15 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] * In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:08:07 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. As I said in another message, in Emacs, M-x vc-rename-file RET will work when the back-end is RCS or SCCS, but not when it is CVS. Do you have any clue at all what you're talking about? Do you really know what vc-rename-file does? Do you understand the temporal consequences of such an operation? It would seem not. I have no idea what SCCS is, but I thought that RCS was _more_ primitive than CVS. Well, CVS is little more than a simple integrated wrapper around RCS. It could have been built just about as easily on SCCS, which is really just a silghtly better (but a little more restricted) tool like RCS. CVS isn't really more or less primitive than RCS from an overal change management process perspective. All CVS does is make it possible to automate a number of RCS operations in a convenient manner. All the problems you are talking about here (merging c) arise for one simple reason - you do not have cvs mv and you make people think that cvs add/rm has anything to do with renaming. It's FAR deeper than that I'm afraid. Here's a simple cvs-mv script for you: #! /bin/sh # # cvs-mv -- for the command-line challenged # if [ $# -ne 2 -o ! -f $1 -o ! -f $2 ] ; then echo usage: cvs-mv oldfile newfile 21 exit 2 fi # oldpath=$1 newpath=$2 oldfile=$(basename $oldpath) newfile=$(basename $newpath) olddir=$(dirname $oldpath) newdir=$(dirname $newpath) cp $oldpath $newpath cd $olddir cvs rm -f $oldfile cd - cd $newdir cvs add $newpath cd - cvs commit -m renamed '$oldpath' to '$newpath' $oldpath $newpath There. Are you happy now? -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 18:16:55 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? why can't cvs mv just rename the *,v file? R.T.F.M. PLEASE! -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 17:31:05 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Why can't I see the log for all of them in one command? Because that's not the way CVS works. Consider a versioning file system which has a native idea of file version. I can rename file FOO;latest to BAR;latest, keeping the older versions of FOO named FOO;1, FOO;2 c. - this corresponds to the CVS method (rm/add). But I also can rename _all_ version of FOO to BAR. This _is_ a reasonable thing to do. Why can't I do it with CVS? Because that's not the way CVS works. Please note that the answers like this is not how CVS manages change! are not very convincing, because the natural retort is then maybe CVS manages change incorrectly? Well, maybe you should try a little harder to learn how CVS works and find out what it's really doing internally. Even the manual discusses most of the issues regarding renames quite clearly and accurately. Please tell us _why_ the request for the CVS command mv, which would rename the *,v file and replace the CVS/Entries entry is unreasonable. (Oh yeah, CVSROOT/history should also be suitably modified and a record of the renaming to allow for undoing it should also be added. But is these are too hard to implement, forget it and stick with a simple mv FOO,v BAR,v). CVS cannot do what you want it to do. The reasons why not have been discussed almost infinitely. Some new tool might someday be able to do this, and several commercial tools claim to be able to already. And while I am talking about undoing, why can't a revision be removed from the CVS? just like I can remove a revision in a versioning file system, I should be able to remove a revision from the CVS. You can, but you shouldn't. The proper way to undo, or revert, a change in any change tracking system is to apply the change as a reverse patch, thus removing the change from the new file, and then commit that as a new change again, noting in the commit message which delta you've reverted. Don't get me wrong. CVS is a great tool. Let's make it even better! To make CVS do what you want will require changes so extensive and ground shaking that the result will no longer interoperate with a normal CVS repository. The transformation will be complete and it will create a new tool. Word is people are already working on such a thing -- whether they'll succeed or not is yet to be seen. Note that Perforce and BitKeeper already claim to have rename support, and BitKeeper claims to have the best rename support of all. Howeve even in BitKeeper Conceptually, a rename is seen as a deletion of one file and a creation of another file. So, there you have it. -- 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: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from Greg Woods: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! You do, if the version history of FOO is part of the history of BAR, having become that way by way of a reorganization of the project. Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. Until you understand why the design of CVS is broken, you will never understand why this is a reasonable expectation. Go away and figure it out. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Dave Storrs wrote: Hi Miklos, What he means is this: let's say that you want to rename file foo.c in your working copy to bar.c, and you want the name change to sync up in the repository, without losing any of foo.c's version history. You would then do the following: - Make sure no one else is accessing the repository right now. The way you do that is by creating a lock directory. - 'cd' into the repository, find the file named foo.c,v - 'mv foo.c,v bar.c,v' Before you do anything, mkdir #cvs.lock. If that fails, wait and try again. Note that Karl Fogel already provided the advice of cp'ing the file. This is more sensible because it produces a new object without destructively manipulating the old. So foo.c,v is still there with its version history intact; you merely have a duplicate. The best way is to do this from the working copy. Copy your working foo.c to bar.c. Then do: cvs add bar.c rm foo.c cvs rm and commit. In other words, cvs remove the old, add the new. I've done this and it works, as long as no one is doing a checkout or update while you are renaming (if they are, results are undefined (==openly hostile, as KR once remarked)). You could have found out on how to place a lock with a tiny amount of RTFM. The only downside is that you will not be able to reconstruct the project as it did before you did this rename...because CVS will not be able to serve up the file foo.c file for you. And after that downside, you think there is still an upside? Version control has gone out the window basically. Bye bye tagged, reproducible builds. There are other downsides, like people's working copies having dangling references to a nonexistent version file. People may have local modifications to the renamed file. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Wednesday, October 10, 2001 at 10:52:04 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Generally speaking, renaming stuff in CVS is royal pain. You always lose something. It's up to you to decide what you're willing to give up. You never loose anything if you do it right. (and assuming some bugs are fixed in some ancillary sub-commands) -- 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: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Wed, 10 Oct 2001 15:06:14 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On Wednesday, October 10, 2001 at 10:52:04 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Generally speaking, renaming stuff in CVS is royal pain. You always lose something. It's up to you to decide what you're willing to give up. You never loose anything if you do it right. (and assuming some bugs are fixed in some ancillary sub-commands) if you rename FOO to BAR the right way, i.e., $ mv FOO BAR $ cvs rm FOO $ cvs add BAR $ cvs ci BAR then you lose in many ways: * 'cvs log BAR' does not list changes in file FOO * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) This is why I usually rename the *,v files, edit them manually to replace file names in $Id$ and also edit history. The problem is that I do not always have shell access - then I am stuck. Ideally I want to be able to say $ cvs rename -r 2.0 FOO BAR so that BAR 2.0 is the same as the current FOO. then BAR 1.123 will be the same as FOO 1.123. CVS would know that FOO and BAR are the same logical file. $ cvs co -r 1.123 BAR and $ cvs co -r 1.123 FOO would create a file named FOO while $ cvs co -r 2.0 BAR and $ cvs co -r 2.0 FOO would create a file named BAR -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ Only adults have difficulty with childproof caps. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Wednesday, October 10, 2001 at 14:40:11 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In one method, you lose the ability to get a file's entire revision history in one place (i.e. you must track down its old location(s) and fetch additional history from there). That's not a loss, nothing is lost -- that a stupid illogical complaint. -- 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: [kfogel@collab.net: Re: rename in cvs]
[ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] if you rename FOO to BAR the right way, i.e., $ mv FOO BAR $ cvs rm FOO $ cvs add BAR $ cvs ci BAR then you lose in many ways: No, you lose absolutely nothing -- in fact you _gain_ the information about the rename! * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. The problem is that I do not always have shell access - then I am stuck. You don't need to have shell-level access to the repository. -- 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: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
