Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 14:14:21 I think perhaps you are speaking as a cvs developer here not a cvs user. To me "cvs unedit" has a closer meaning in english for reverting files than "cvs update". But I guess the "cvs update -C" isn't technically reverting files. Its updating them and throwing away any local changes. I would still like to see "cvs unedit" actually revert files (i.e. restore to the version you were editting instead of the latest version). I just wanted to say that, perhaps "cvs reserve" and "cvs unreserve" would be better (although not perfect) names for "cvs edit" and "cvs unedit". Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.24 02:10:47 Hm... If unedit will not modify the existing file than what is the use of backup? The same purpose it serves for "cvs up" and other CVS commands -- for the user to use at his/her discretion. Well, so far that backup copy of the file was rather to CONFuse (same name, writable, in the subdirectory near the original...)... We should be clear on which backup we're talking about. There's the backup in the current implementation of "cvs edit" (the one existing in CVS/Base) and there's the canonical one for other CVS commands (the one's starting with .#). My patch changes the behaviour of "cvs edit" such that the backup is the canonical one. It does away with CVS/Base. Like I said, you would need at least two new flags. One to get the behaviour you want, another to override it in case it's in your .cvsrc file. Sowhy not? If someone wants to do this, they can. I have no need for it personally. A word of warning, though. Unless "cvs co" is changed to save a copy of the file (as it is upon checkout), "cvs unedit" will never be able to revert back to that copy. Also, the processing of "cvs unedit" will have to change drastically to ensure atomicity. For example, if you decide to revert files and only some of the succeed, you will wind up with an inconsistent set of files. The patch very useful to me the way I did it. Again, you're welcome to patch the patch if you want. Nope - I will ignore that patch since my patch to your patch is to revert to the previous version 'cause I see no gain in your patch at the moment You can do this, too. The fact that they are documented /and/ consistent makes them not side effects (ie predictable behaviour). Well, still all you get is a well documented and predicatble side effects... My definition of "side effect" is something that occurs that can affect another operation that's orthogonal to the original operation. If someone edited the backup or did several series of modifications and "cvs edit", then a "cvs unedit" sometime down the road will be affected. What's your definition. How does it apply to my patch? It's named .#foo.c right now (in my patch). I don't see why your grep tools would pick that up. I'll look into tagging the revision number on the end of it, but it might affect other commands' backups (IMHO, this is A Good Thing, anyway). It will pick it up 'cause grep works on the file extenstions. That is why to change extension in crutial for that patch to work nice way with the grep tools. ".#foo._c" would do. Right, sometimes I forget some people actually use Windows and DOS shells. I think tagging on the version number would be A Good Thing. More precisely, a "cvs edit" backup should probably look like ".#foo.c.1.2+". Note the '+' that denotes that there might be some local modifications within this backup. I don't understand. The patch I posted solves a set of problems (but perhaps not yours). I, in no way, hardcoded anything specific to my company. The solution is generic. You are hardcoding your working pattern - drive carefully here. I don't think that I am since (I think) we both agree that a trustable reversion is impossible within the context of CVS alone. It is not impossible within the context of, for example, WinCVS, though. Yes, but "cvs edit" and "cvs unedit" NEVER worked the way you or the others expected it to. WinCVS forces the behaviour you see now by wrapping CVS. That's a perfectly good solution to your problem. We don't really have the problem with edit/unedit. We will have the problem after your patch I think... :) Not if you patch WinCVS. snip Unfortunately, you guys seem to have a different idea of what CVS is than I do. Perhaps you should look at the code yourself to see how difficult (or even impossible) it is to do what you want (specially given that "cvs edit" and "cvs unedit" should work offline). No, I think our ideas are quite close. THere are small differences on the details, but I am sure we can work it out. I believe that you are able to make it comfortable for both sides. Not if valid reversions are impossible for "cvs unedit". Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.21 17:43:11 The interface to CVS with my patch is: "cvs edit" will save a backup using the standard naming conventions for backups. "cvs unedit" will not modify the existing file. This is an extremely simple interface. Hm... If unedit will not modify the existing file than what is the use of backup? The same purpose it serves for "cvs up" and other CVS commands -- for the user to use at his/her discretion. If flags were added, there'd be a few unlesses for the "cvs unedit" interface. It'd be more complicated. Yep, but many functionality is already there, it might just need "-f" to force the revert from backup. Like I said, you would need at least two new flags. One to get the behaviour you want, another to override it in case it's in your .cvsrc file. It doesn't matter if it's complicated, it must be USEFUL first of all. The patch very useful to me the way I did it. Again, you're welcome to patch the patch if you want. If so, those side effects are highly documented and consistent (ie they're not side effects). Since when "documented side effects" stop to be ones? They're still side effects. The fact that they are documented /and/ consistent makes them not side effects (ie predictable behaviour). Note also that the side effect of automatically using a mangled backup won't be seen until "cvs unedit". This may not occur for days or weeks or ... Such a side effect is horrendous. Users will constantly be posting "cvs unedit" bug reports due to their actions (which they most certainly will have forgotten by the time the "cvs unedit"). No they can't. What part of "\"cvs edit\" saves a copy of the file the way it was at the time of \"cvs edit\"" don't you understand? Or, can you explain how you'd go about using timestamps to figure out if something has happened to the backup? OK, forget about the timestamps. Just: 1. make it readonly. OK, I just checked this. It currently doesn't make the backup read-only. I'll change this (unless I find that I had a reason not to). 2. rename it a bit to avoid the cinfusion, especially change the extension so the grep tools will no more pick it up. THe way to rename with the revision number appended to the name sounds as a perfect solution. It's named .#foo.c right now (in my patch). I don't see why your grep tools would pick that up. I'll look into tagging the revision number on the end of it, but it might affect other commands' backups (IMHO, this is A Good Thing, anyway). This two steps are simple, consistent and USEFUL, they don't breake current behaviour and they solve most problems with the backup copy. OK. I haven't been able to figure out a way to see if there is a connection or not. Perhaps someone can help out here? I've seen other occassions to know the connectability status. You can just attempt normal connection and wait to see if it will fail. I haven't seen an easy way to do that with the CVS code the way it is. If you can suggest exactly how (ie source code) that can be done, I'd appreciate it. From what I've seen in the past, you seem to have been hacking WinCVS. If this is true, you should be able to easily (since the interface is so simple) hack WinCVS to do most of what you want. Sure I can. But I would not for example attempt to put the code with hardcoded setting to access my company repository into the public. I patch to my needs but FIRST of all I will think how common problem and how generic solution is. I don't understand. The patch I posted solves a set of problems (but perhaps not yours). I, in no way, hardcoded anything specific to my company. The solution is generic. What I'm saying is that you can patch WinCVS to account for the patch (you know exactly what comes out of "cvs edit", you can therefore change the WinCVS unedit to suit your needs). If you feel otherwise, don't use my patch (or patch it up some more). Seriously, though, none of the others have jumped in 'cos they don't use "cvs edit" and "cvs unedit". I think I'm the only one who does who also wants to maintain the CVS philosophy of keeping the tool simple. Hm... the others did jumped, Most if not all WinCvs users are using edit/unedit all the time since that is how the tool works best. Yes, but "cvs edit" and "cvs unedit" NEVER worked the way you or the others expected it to. WinCVS forces the behaviour you see now by wrapping CVS. That's a perfectly good solution to your problem. They are complaining about your patch, "hear the voices" and maybe revise your patch a little bit? I don't think so. They're complaining that my patch brings to the surface the true behaviour of "cvs edit" and "cvs unedit". They don't like that behaviour. The only way to fix it is to wrap it. A patch to CVS to "fix" it (I really don't see a problem) will make CVS much more complicated (just look at your suggestions to fix it). Onestly I was hoping that one day we would support RCVS at least to get
Re: Base directory, in CVS directory
Noel L Yap wrote: [EMAIL PROTECTED] on 2000.07.20 13:37:52 Yes, this behaviour is consistent with OOTB CVS (ie without "cvs edit"). For example: cvs co module cd module cat hello file # OOTB CVS has files read-write What does OOTB mean? Out of the box. cvs ci # will checkin file If you don't want this behaviour, use the "cvs ci -c" patch which'll check for valid edits before committing. So, if I understand you correctly, I can "cvs unedit" a file which will still leave it in its modified state and then check it in. Yes. I assume that the watchers will get the "commit" notification but they won't get the "edit" notification because the developer has used "unedit". They would get the edit notification when the user first did "cvs edit". They would get the unedit notification when the user did "cvs unedit". They will get the commit notification when the user did "cvs ci". I don't quite see the point in having edit watches if they can be defeated like this but they can also be defeated by using chmod. I couldn't agree more. Of course you can use chmod or other trics to defeat the system in any case. The important thing is that an unedit that does not revert makes it possible to committ the edited file by accident if the developer forgets to revert the file manually. There is a very significant differenct between a tool and user interface design that can be overridden by a skilled user, and a design that makes these kinds of accidents possible. Exactly. "cvs edit" and family are meant to /facilitate/ communication. They're not meant to enforce communication. For example, I habitually chmod when all I want to do is add a debug printf. If later I find that I really want to commit the file in the future, I'll "cvs edit" it. I my mind, a good version control system should always enforce consitency and safety by default (but let you break the rules if when have to). The described edit/unedit behaviour seems to follow the opposite philosophy: Do it right if you want to... I really don't think that is a good idea. Others might dissagree. I'm really really happy that WinCVS wraps this stupid CVS behaviour for me to make edit/unedit behave in a logical and sound way. If I have the time I will look into a way to make CVS 1.10 make the files in the "Base" folder write protected to prevent myself and other developers from inadvertently editing these files after double-clicking on the file in the search result list in Developer's Studio. That's the only change I need. I somebody knows how to do this or have already done so, please let the rest of us know. I might check in RCVS later to see in which direction things are going, but I'll think leave you alone for now. Things seem to be going in the wrong direction here at the moment. - Helge Penne
Re: Base directory, in CVS directory
Hi, If I have the time I will look into a way to make CVS 1.10 make the files in the "Base" folder write protected to prevent myself and other developers from inadvertently editing these files after double-clicking on the file in the search result list in Developer's Studio. That's the only change I need. I somebody knows how to do this or have already done so, please let the rest of us know. For Developer Studio the problem is solved for you if you use CvsIn. It will kindly warn you if you try to open the file which is in the "*/Cvs/Base/" directory and tell you not to edit it. So it is not important that the file is writable - you will get the message box each time you activate such file in the DevStudio. CvsIn is a free, open source Add-in for the DevStudio, look for it at: www.cvsin.org or http://www.geocities.com/kaczoroj/CvsIn/ As a side note I will only mention that sometime next week there will be an internal CvsIn Beta release (you would have to join the CvsIn mailing list to get it) which is using the file's copy in the /Cvs/Base/ to call an external diff. It works fast and it doesn't require the connection to the server. It will also show YOUR changes YOU made to the file since you made 'cvs edit', which is also good. Funny is that I used to hate that copy in the /Base/ directory, now I've found a usage for it :) Personally I think I want Unedit to revert the file's changes. WinCvs and CvsIn (well, cvs.exe in fact) gives an option to revert the changes or not if the file has been modified. I would rather want some patch to allow me to force the revert and not having to interact with CVS at that point. It complicates the shelling of cvs.exe client if Unedit is interactive. BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks.
Re: Base directory, in CVS directory
O. Thanks! If it works as advertised it will both solve our problem and add a few nice new features as well. - Helge Penne "Win32 M$" wrote: Hi, If I have the time I will look into a way to make CVS 1.10 make the files in the "Base" folder write protected to prevent myself and other developers from inadvertently editing these files after double-clicking on the file in the search result list in Developer's Studio. That's the only change I need. I somebody knows how to do this or have already done so, please let the rest of us know. For Developer Studio the problem is solved for you if you use CvsIn. It will kindly warn you if you try to open the file which is in the "*/Cvs/Base/" directory and tell you not to edit it. So it is not important that the file is writable - you will get the message box each time you activate such file in the DevStudio. CvsIn is a free, open source Add-in for the DevStudio, look for it at: www.cvsin.org or http://www.geocities.com/kaczoroj/CvsIn/ As a side note I will only mention that sometime next week there will be an internal CvsIn Beta release (you would have to join the CvsIn mailing list to get it) which is using the file's copy in the /Cvs/Base/ to call an external diff. It works fast and it doesn't require the connection to the server. It will also show YOUR changes YOU made to the file since you made 'cvs edit', which is also good. Funny is that I used to hate that copy in the /Base/ directory, now I've found a usage for it :) Personally I think I want Unedit to revert the file's changes. WinCvs and CvsIn (well, cvs.exe in fact) gives an option to revert the changes or not if the file has been modified. I would rather want some patch to allow me to force the revert and not having to interact with CVS at that point. It complicates the shelling of cvs.exe client if Unedit is interactive. BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks. -- Helge Penne ([EMAIL PROTECTED]) Senior Software Development Engineer Data Respons AS, Postboks 489, N-1323 Høvik, Norway Phone: +47 67112081 / 22719957 (work/home)
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.21 03:02:56 I don't quite see the point in having edit watches if they can be defeated like this but they can also be defeated by using chmod. I couldn't agree more. Of course you can use chmod or other trics to defeat the system in any case. The important thing is that an unedit that does not revert makes it possible to committ the edited file by accident if the developer forgets to revert the file manually. There is a very significant differenct between a tool and user interface design that can be overridden by a skilled user, and a design that makes these kinds of accidents possible. Then don't use CVS (which you're not, you're using WinCVS -- a wrapper). By default, the following is possible: cvs co module # all files are checked out read-write cd module echo hello file # assuming file already exists cvs ci WinCVS hides this behaviour from you. It can also hide the non-modifying "cvs unedit" from you. Exactly. "cvs edit" and family are meant to /facilitate/ communication. They're not meant to enforce communication. For example, I habitually chmod when all I want to do is add a debug printf. If later I find that I really want to commit the file in the future, I'll "cvs edit" it. I my mind, a good version control system should always enforce consitency and safety by default (but let you break the rules if when have to). The described edit/unedit behaviour seems to follow the opposite philosophy: Do it right if you want to... I really don't think that is a good idea. Others might dissagree. Obviously, I disagree ;) Or, at least, I disagree what "right" is in this circumstance. CVS doesn't enforce any policy. If you want to enforce policy, wrap CVS. I might check in RCVS later to see in which direction things are going, but I'll think leave you alone for now. Things seem to be going in the wrong direction here at the moment. Again, we disagree on what "right" and "wrong" are. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.21 04:58:09 Personally I think I want Unedit to revert the file's changes. WinCvs and CvsIn (well, cvs.exe in fact) gives an option to revert the changes or not if the file has been modified. I would rather want some patch to allow me to force the revert and not having to interact with CVS at that point. It complicates the shelling of cvs.exe client if Unedit is interactive. When I first made this patch, I decided for two reasons not to add "cvs unedit" flags to revert or keep changes: 1. Flags complicate the interface to "cvs unedit". 2. The backup copy can't be trusted since the user can easily do something to it now. So, any modifications to the backup have side effects affecting "cvs unedit". Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
Dear Noel, When I first made this patch, I decided for two reasons not to add "cvs unedit" flags to revert or keep changes: 1. Flags complicate the interface to "cvs unedit". ?! What kind of argument is that? NOT having the flags complicates the interface to cvs! Come on, all CVS commands have zillions of flags, why unedit can't have...? Since flags are not compulsory, just helpful, the argument of 'complication' can not stand. 2. The backup copy can't be trusted since the user can easily do something to it now. So, any modifications to the backup have side effects affecting "cvs unedit". This is true, but the solution you propose seems to have even more side effects! The chance that something actually happened to the backup are quite small, and could be detected for example with the time-stamp. Also, making a backup read-only would solve about 99% of the problem. Additionally backup name could be changed so it doesn;t look like the original file and thus it is easier to detect mistake. I think to add the revision number after the filename (like the conflict does) would almost solve the remaining 1% of the problem after making the file read-only.if you could make a patch that way: 1. During making a backup: a) the backup is created as read-only. Eventually the timestamp is recorded to allow the detection of accidental modification. b) the backup name is the original filename + revision number instead of the same name as original, eg. file foo.c is backed up as foo.c.2.12 2. During unedit: a) check if there is a connection to the repo. if it is then attempt to get the revision from repo. b) if no repo connection is at hand then check if the original file was modified, if it was then check if it backup was modified. give the choice for the user: o do not revert o revert to the backup (with the warning if the copy is modified) o offer the attemp to connect to the repo. 3. unedit should have the flag to force the revert, the important part is to not have cvs interact with the user so the shelling and scripting othe unedit is possible and easy. If you are attempting to solve the problems around edit/unedit then do it right. Do not make patch which creates more problems than it solves. I seem to not be alone in that feeling. Best Regards, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.21 14:12:25 When I first made this patch, I decided for two reasons not to add "cvs unedit" flags to revert or keep changes: 1. Flags complicate the interface to "cvs unedit". ?! What kind of argument is that? NOT having the flags complicates the interface to cvs! Come on, all CVS commands have zillions of flags, why unedit can't have...? Since flags are not compulsory, just helpful, the argument of 'complication' can not stand. Saying that CVS has zillions of flags is hyperbole. If you want to see what zillions of flags is, look at ClearCase. The interface to CVS with my patch is: "cvs edit" will save a backup using the standard naming conventions for backups. "cvs unedit" will not modify the existing file. This is an extremely simple interface. If flags were added, there'd be a few unlesses for the "cvs unedit" interface. It'd be more complicated. 2. The backup copy can't be trusted since the user can easily do something to it now. So, any modifications to the backup have side effects affecting "cvs unedit". This is true, but the solution you propose seems to have even more side effects! If so, those side effects are highly documented and consistent (ie they're not side effects). The chance that something actually happened to the backup are quite small, and could be detected for example with the time-stamp. No they can't. What part of "\"cvs edit\" saves a copy of the file the way it was at the time of \"cvs edit\"" don't you understand? Or, can you explain how you'd go about using timestamps to figure out if something has happened to the backup? Also, making a backup read-only would solve about 99% of the problem. I think I already do this, but I'm not sure. I don't think I'm opposed to doing this. Additionally backup name could be changed so it doesn;t look like the original file and thus it is easier to detect mistake. The backup is meant to look at least a little like the original so the user /is/ able to use it. All I do is use the standard file backup routine. If you want to change that, that's fine by me (so long as the new name is still easily computable from the original name). I think to add the revision number after the filename (like the conflict does) would almost solve the remaining 1% of the problem after making the file read-only.if you could make a patch that way: 1. During making a backup: a) the backup is created as read-only. Eventually the timestamp is recorded to allow the detection of accidental modification. See above with regards to write bit. Where is the timestamp recorded? In any event, this'll complicate the code a lot. If someone else wants to do it, they can. b) the backup name is the original filename + revision number instead of the same name as original, eg. file foo.c is backed up as foo.c.2.12 I'd like to keep backup filenames consistent among the commands. In all, I like the idea of having the revision as part of the backup filename. Something like .#foo.c.2.12 would be good (although it should be very rare that you see a major revision number other than 1). 2. During unedit: a) check if there is a connection to the repo. if it is then attempt to get the revision from repo. I haven't been able to figure out a way to see if there is a connection or not. Perhaps someone can help out here? I've seen other occassions to know the connectability status. b) if no repo connection is at hand then check if the original file was modified, if it was then check if it backup was modified. give the choice for the user: The most you can check (with your timestamp scheme) is whether the file has been modified sometime after the "cvs edit". You won't be able to see if the file has been modified between "cvs co" and "cvs edit". o do not revert o revert to the backup (with the warning if the copy is modified) o offer the attemp to connect to the repo. This would make "cvs unedit" interactive (ie non-batchable). This was one thing I removed on purpose. Maybe it should just error out (atomically, of course, so that no other files will be uneditted). Connecting to the repo at this time may be impossible with the current architecture. Then again, I'm not too knowledgable about this part of the code. 3. unedit should have the flag to force the revert, the important part is to not have cvs interact with the user so the shelling and scripting othe unedit is possible and easy. Both keep and revert will need flags (so people can override what's in their .cvsrc files). If you are attempting to solve the problems around edit/unedit then do it right. Do not make patch which creates more problems than it solves. I seem to not be alone in that feeling. I did it right (at least for my needs). If you feel otherwise, don't use my patch (or patch it up some more). Seriously, though, none of the others have jumped in 'cos they don't use "cvs edit" and "cvs unedit". I think
Re: Base directory, in CVS directory
Dear Noel, The interface to CVS with my patch is: "cvs edit" will save a backup using the standard naming conventions for backups. "cvs unedit" will not modify the existing file. This is an extremely simple interface. Hm... If unedit will not modify the existing file than what is the use of backup? The interface is "extremely simple" in the worst meaning of "extreme". If flags were added, there'd be a few unlesses for the "cvs unedit" interface. It'd be more complicated. Yep, but many functionality is already there, it might just need "-f" to force the revert from backup. It doesn't matter if it's complicated, it must be USEFUL first of all. If so, those side effects are highly documented and consistent (ie they're not side effects). Since when "documented side effects" stop to be ones? They're still side effects. No they can't. What part of "\"cvs edit\" saves a copy of the file the way it was at the time of \"cvs edit\"" don't you understand? Or, can you explain how you'd go about using timestamps to figure out if something has happened to the backup? OK, forget about the timestamps. Just: 1. make it readonly. 2. rename it a bit to avoid the cinfusion, especially change the extension so the grep tools will no more pick it up. THe way to rename with the revision number appended to the name sounds as a perfect solution. This two steps are simple, consistent and USEFUL, they don't breake current behaviour and they solve most problems with the backup copy. I haven't been able to figure out a way to see if there is a connection or not. Perhaps someone can help out here? I've seen other occassions to know the connectability status. You can just attempt normal connection and wait to see if it will fail. From what I've seen in the past, you seem to have been hacking WinCVS. If this is true, you should be able to easily (since the interface is so simple) hack WinCVS to do most of what you want. Sure I can. But I would not for example attempt to put the code with hardcoded setting to access my company repository into the public. I patch to my needs but FIRST of all I will think how common problem and how generic solution is. If you feel otherwise, don't use my patch (or patch it up some more). Seriously, though, none of the others have jumped in 'cos they don't use "cvs edit" and "cvs unedit". I think I'm the only one who does who also wants to maintain the CVS philosophy of keeping the tool simple. Hm... the others did jumped, Most if not all WinCvs users are using edit/unedit all the time since that is how the tool works best. They are complaining about your patch, "hear the voices" and maybe revise your patch a little bit? Onestly I was hoping that one day we would support RCVS at least to get 'csv edit -c' functionality and kick off the admin locks. Try to keep RCVS more/less consistent with the CVS...? Cheers, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 07:44:23 Maybe we don't understand each other properly. I've mostly used CVS through WinCVS. The default WinCVS setup uses watches, wihich requires that you use "edit" to make the file writeable before you edit it (all files are read only after checkout). "unedit" reverts the file to the state it had before the "edit" command (the last revision on the current branch in the server's database). I really don't understand your claim that ""cvs unedit" never reverted the file back to the original version.". It certainly does so when I use WinCVS. The CVS manual confirms that the behaviour I descirbed above is the correct and expected "update" behavior when watches are in use (as they are by default with WinCVS). I see. WinCVS wraps around CVS to hide this behaviour. I'll give you an example using command lines: cvs co module cd module chmod +w file echo hello file cvs edit file echo goodbye file cvs unedit file # file will still have "hello" tagged to the end of it The reasons why this happens are: 1. "cvs edit" and "cvs unedit" are supposed to work offline. 2. Since "cvs unedit" is supposed to work offline, it cannot retrieve a copy from the repository. 3. Therefore, "cvs unedit" relies on "cvs edit" to save a copy in CVS/Base. 4. Since "cvs edit" is supposed to work offline, it saves the current local copy in CVS/Base. The documentation is dead wrong. Instead of complicating the documentation (by describing that "cvs unedit" will revert the file back to the copy at the time of "cvs edit"), it's much easier to simplify both the documentation and the code (by saying that "cvs unedit" doesn't unmodify code). You change will break this behaviour and make the behaviour of edit/unedit asymmetrical, in that sense that unedit will no longer undo the changes made by and after the edit command. Besides removing the file from watch lists, this is the only propuse of unedit and changing it the way you describes seems like a bad idea to me. Since WinCVS wraps around CVS, it should be changed to maintain its current behaviour. Could you elaborate what you mean is wrong with the current unedit behaviour (besides the creation of files in the Base-folder)? I've heard you argument that minimal is good. Generally speaking that is true, but this new behaviour seems a bit too minimal for my taste... See above. You see, one of my worries is that if unedit does not revert to the original file, then the user is removing himself from the watch list but he/she is still editing the file, since the local copy is different from the one on the server, and this changed file will probably still be committed later if the user does a recursive committ from a higher level. This will seriously break the fundamental logic of the watch lists. Seems like a bad idea to me. This is why I posted a "cvs ci -c" patch that makes sure the user committing the files has valid edits on them. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
Noel Yap wrote: The documentation is dead wrong. Instead of complicating the documentation (by describing that "cvs unedit" will revert the file back to the copy at the time of "cvs edit"), it's much easier to simplify both the documentation and the code (by saying that "cvs unedit" doesn't unmodify code). If it doesn't "unmodify" code, what is its purpose, then? -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.tgivan.com/ TGI Technologieshttp://www.pop-star.net/
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 12:25:36 Noel Yap wrote: The documentation is dead wrong. Instead of complicating the documentation (by describing that "cvs unedit" will revert the file back to the copy at the time of "cvs edit"), it's much easier to simplify both the documentation and the code (by saying that "cvs unedit" doesn't unmodify code). If it doesn't "unmodify" code, what is its purpose, then? Exactly what the command is, "cvs unedit". It removes the edit from the file and notifies watchers of the action. I forget how I had it treat the write bit (in my patch). Remember, "cvs edit" and family are there to facilitate communication among developers. Nothing else. So, what happens when you try and commit that module. Will it commit that file or not? -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.tgivan.com/ TGI Technologieshttp://www.pop-star.net/
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 12:25:36 Noel Yap wrote: The documentation is dead wrong. Instead of complicating the documentation (by describing that "cvs unedit" will revert the file back to the copy at the time of "cvs edit"), it's much easier to simplify both the documentation and the code (by saying that "cvs unedit" doesn't unmodify code). If it doesn't "unmodify" code, what is its purpose, then? Exactly what the command is, "cvs unedit". It removes the edit from the file and notifies watchers of the action. I forget how I had it treat the write bit (in my patch). Remember, "cvs edit" and family are there to facilitate communication among developers. Nothing else. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 12:52:32 If it doesn't "unmodify" code, what is its purpose, then? Exactly what the command is, "cvs unedit". It removes the edit from the file and notifies watchers of the action. I forget how I had it treat the write bit (in my patch). Remember, "cvs edit" and family are there to facilitate communication among developers. Nothing else. So, what happens when you try and commit that module. Will it commit that file or not? Yes, this behaviour is consistent with OOTB CVS (ie without "cvs edit"). For example: cvs co module cd module cat hello file # OOTB CVS has files read-write cvs ci # will checkin file If you don't want this behaviour, use the "cvs ci -c" patch which'll check for valid edits before committing. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
Noel Yap wrote: [EMAIL PROTECTED] on 2000.07.20 12:52:32 If it doesn't "unmodify" code, what is its purpose, then? Exactly what the command is, "cvs unedit". It removes the edit from the file and notifies watchers of the action. I forget how I had it treat the write bit (in my patch). Remember, "cvs edit" and family are there to facilitate communication among developers. Nothing else. So, what happens when you try and commit that module. Will it commit that file or not? Yes, this behaviour is consistent with OOTB CVS (ie without "cvs edit"). For example: cvs co module cd module cat hello file # OOTB CVS has files read-write What does OOTB mean? cvs ci # will checkin file If you don't want this behaviour, use the "cvs ci -c" patch which'll check for valid edits before committing. So, if I understand you correctly, I can "cvs unedit" a file which will still leave it in its modified state and then check it in. I assume that the watchers will get the "commit" notification but they won't get the "edit" notification because the developer has used "unedit". I don't quite see the point in having edit watches if they can be defeated like this but they can also be defeated by using chmod. Personally, I would like to see some sort of module "revert" command. Currently, I can only revert a file at a time by doing: rm file cvs update file Conceivably, I could write a script or an alias to do this recursively for every sub-module but I would prefer that cvs supported it "out of the box". To me, the meaning of "unedit" is the ideal command to do this. So all I would do is: cvs unedit module and it would revert all my changes in module and all its sub-modules. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.tgivan.com/ TGI Technologieshttp://www.pop-star.net/
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 13:37:52 Yes, this behaviour is consistent with OOTB CVS (ie without "cvs edit"). For example: cvs co module cd module cat hello file # OOTB CVS has files read-write What does OOTB mean? Out of the box. cvs ci # will checkin file If you don't want this behaviour, use the "cvs ci -c" patch which'll check for valid edits before committing. So, if I understand you correctly, I can "cvs unedit" a file which will still leave it in its modified state and then check it in. Yes. I assume that the watchers will get the "commit" notification but they won't get the "edit" notification because the developer has used "unedit". They would get the edit notification when the user first did "cvs edit". They would get the unedit notification when the user did "cvs unedit". They will get the commit notification when the user did "cvs ci". I don't quite see the point in having edit watches if they can be defeated like this but they can also be defeated by using chmod. Exactly. "cvs edit" and family are meant to /facilitate/ communication. They're not meant to enforce communication. For example, I habitually chmod when all I want to do is add a debug printf. If later I find that I really want to commit the file in the future, I'll "cvs edit" it. Personally, I would like to see some sort of module "revert" command. Currently, I can only revert a file at a time by doing: rm file cvs update file "cvs up -C" will revert files back to the repository copy. This is available in cvs-1.10.8. I've posted a patch to fix a bug dealing with merges. Conceivably, I could write a script or an alias to do this recursively for every sub-module but I would prefer that cvs supported it "out of the box". To me, the meaning of "unedit" is the ideal command to do this. So all I would do is: cvs unedit module and it would revert all my changes in module and all its sub-modules. "cvs up" is the ideal place to do this, not "cvs unedit". Like I said, "cvs unedit" is to facilitate communication -- nothing more, nothing less. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
Noel Yap wrote: [EMAIL PROTECTED] on 2000.07.20 13:37:52 Personally, I would like to see some sort of module "revert" command. Currently, I can only revert a file at a time by doing: rm file cvs update file "cvs up -C" will revert files back to the repository copy. This is available in cvs-1.10.8. I've posted a patch to fix a bug dealing with merges. That's cool. I can use that. Conceivably, I could write a script or an alias to do this recursively for every sub-module but I would prefer that cvs supported it "out of the box". To me, the meaning of "unedit" is the ideal command to do this. So all I would do is: cvs unedit module and it would revert all my changes in module and all its sub-modules. "cvs up" is the ideal place to do this, not "cvs unedit". Like I said, "cvs unedit" is to facilitate communication -- nothing more, nothing less. I think perhaps you are speaking as a cvs developer here not a cvs user. To me "cvs unedit" has a closer meaning in english for reverting files than "cvs update". But I guess the "cvs update -C" isn't technically reverting files. Its updating them and throwing away any local changes. I would still like to see "cvs unedit" actually revert files (i.e. restore to the version you were editting instead of the latest version). -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.tgivan.com/ TGI Technologieshttp://www.pop-star.net/
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.20 14:14:21 "cvs up" is the ideal place to do this, not "cvs unedit". Like I said, "cvs unedit" is to facilitate communication -- nothing more, nothing less. I think perhaps you are speaking as a cvs developer here not a cvs user. To me "cvs unedit" has a closer meaning in english for reverting files than "cvs update". Yeah, I'd have to agree with you here. Don't blame me, I didn't pick the names of the commands ;) But I guess the "cvs update -C" isn't technically reverting files. Its updating them and throwing away any local changes. Yeah, this is true, too. A real revert would require "cvs up -p -r current revision file file". Unfortunately, I don't know of an easy way to get the base revision number. This could be one or two new proposals: 1. allow a special flag to "cvs up" that means the base version (ie the version checked out). 2. allow a special flag to "cvs stat" that returns the base version only (along with the filename, of course). I would still like to see "cvs unedit" actually revert files (i.e. restore to the version you were editting instead of the latest version). Again, it'll currently restore to the version at the time of "cvs edit". If you want some other behaviour, wrap cvs. I think, like you pointed out, the confusion is in the unfortunate names for "cvs edit" and "cvs unedit". Let me make my definitions clear: "cvs edit":Advertises to watchers that you are modifying the file with the intent of checking it in in the future. This is extremely similar to a checkout in other VC tool terminology. "cvs unedit": Advertises to watchers that you've changed your mind about committing the file in the future. This is extremely similar to an uncheckout in other VC tool terminology. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
Stephen Rasku wrote: I think perhaps you are speaking as a cvs developer here not a cvs user. To me "cvs unedit" has a closer meaning in english for reverting files than "cvs update". But I guess the "cvs update -C" isn't technically reverting files. Its updating them and throwing away any local changes. I would still like to see "cvs unedit" actually revert files (i.e. restore to the version you were editting instead of the latest version). I agree. It seems that the commands are named from the perspective of the repository manager, not the user. --Avi = Avi Green :) (: www.sputnik7.com = Unix S/A System Specialist avi at sputnik7.com 212 217-1147
Re: Base directory, in CVS directory
I've posted my patches to the RCVS project on SourceForge. The "cvs unedit" implementation will not unmodify the file. If you want to have unedit automatically unmodify files you would either have to wrap CVS in a script or submit a patch that allows unmodify operations along with "cvs unedit". I would prefer a flag to "cvs unedit" if you were to go with the latter solution. But, really, the reason I kept this functionality out of "cvs unedit" is to keep the command simple and minimal as is the philosophy of most Unix tools (including CVS). You'd still be able to do what you want by using a wrapper script or function. Noel [EMAIL PROTECTED] on 2000.07.19 09:01:36 To: [EMAIL PROTECTED] cc: Subject: Re: Base directory, in CVS directory --- In [EMAIL PROTECTED], "Noel L Yap" [EMAIL PROTECTED] wrote: Short answer: Use "find ! -path '*/CVS/*'" (if you're using gnu find). Otherwise pipe the output of find through "grep -v '/CVS/' (you might have to backslash the '/'). Long answer: I've come to think that the Base subdirectory is a broken design. 1. The copy stored in Base isn't really the version that was originally checked out, it's the version existing at the time of "cvs edit". 2. "cvs unedit" is interactive due to it's modification check. I propose to: 1. Have "cvs edit" create a backup of the file via the usual means (thereby exposing the backup -- not hiding it within CVS/Base). 2. Have "cvs unedit" solely unedit the file(s) (and perform notifications). "cvs unedit" would no longer unmodify the file(s) -- it would be up to the user to unmodify the file since he/she now knows where the backup is. 3. Get rid of Base (as it'll be unnecessary due to the previous). Noel I agree that this feature should be modified, and that we should get rid of "Base". However, I kind of like the way unedit works today. When I do an unedit I usually want to revert to the way the file was before the edit. Could we please keep the behaviour of unedit as it is? Is somebody working on or planning these modifications at the moment? If there is a patch available, I'd be very interested. - Helge Penne This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.07.19 10:31:17 The change you describle does change the standard behaviour of unedit, since the file no longer reverts to the original version. For what it's worth: My opinion is that unless this is accepted by most CVS users, it is probably your new behaviour that needs an option. The reason is simply that the new default behavior will break or change the behaviour of a lot of tools built on top of CVS. "cvs unedit" never reverted the file back to the original version. It has always (up till my patch) reverted it back to the version existing at the time of "cvs edit". Usually, options should be given to a command to turn things on, not to turn them off. IIRC, I've only gotten one or two complaints including yours. The fact is that most CVS users don't even use "cvs edit" and family. Therefore, there won't be too many broken usages. Those few having scripts relying on the old (IMO broken) behaviour can rewrite their scripts (to copy back the backup file). This new behaviour means that the WinCVS client will no longer work as expected, so in order for things to fix this, I'd have to change WinCVS (in such a way that it might not work with the official CVS release), or patch your patch to make the unedit work again by default. Yes, that's right. Like I said, the existing behaviour is broken -- it doesn't do what it advertises (ie revert the file back), it's not minimal. Would it be a lot of work to make "unedit" revert to the original file (but not use the Base directory)? I know I have no real right to ask, but I think it would make a lot of people happy... If you mean to revert the file back to a copy as it exists in the repository, yes. You can use "cvs up -C" (thanks to Larry, I think) to get a clean copy (I've made a patch to this, too, to fix a bug regarding "cvs up -C" and merges). If you mean to revert back to the version at the time of "cvs edit", edit.c (I think) can be patched to do this. It should be a one-line patch but I won't do it 'cos I believe it is wrong for "cvs unedit" to unmodify the file (especially to an unknown version (ie the version that existed at the time of "cvs edit")). If not, is it simple to make the current CVS 1.10 unedit make the file in the Base directory write protected? We're talking about the WinNT CVS 1.10 client here. Would you happen to know where in the code I would have to make this change? I haven't looked at the code in a while, but, IIRC, it should be. The change should make sure to make the copy writable each time someone does a "cvs edit" (so that it can be overwritten with the latest local copy). I'm not sure what other side effects may occur. All code should be located in edit.c Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Base directory, in CVS directory
[ On Monday, April 3, 2000 at 15:43:43 (CST), Win32 M$ wrote: ] Subject: Base directory, in CVS directory That is a great feature, but the problem is that it is the copy with the exact same name as an original. Then, if I try to grep for the files recursively in some directory, I will get the files in the "Base" as well. More - that files seems to have read-only cleared, so in the end quite often I will edit it instead of the real file... Very annoying... :( That's only a problem with your search tools. If I'm not too far out of touch I seem to recall that the "Base" directory is within the CVS administrative sub-directory. So, you need to purposefully ignore the stuff in the CVS administrative directories. Yes I know this is a bit of a pain and lead to all sorts of simlilar ugliness spread all throughout scripts and tools that build and manage sources, but it's an old and common problem and there are many old and common solutions to it already widely deployed. For example to generate a list of just the non-administrative files: find . -name CVS -prune -o -type f -print If you make this into a shell alias/function/script then you can just pipe its output to 'xargs' to run any command over all the files: just-the-files | xargs grep "string-to-grep-for" Note that a more generic solution for people who work in a wide variety of environments is: find . -name CVS -prune -o -name RCS -prune -o -name SCCS -prune -o -type f -print I'm a touch typist and since I use a wide enough variety of systems the management of such an alias/function/script would be harder for me than just typing the appropriate 'find' command every time. It also helps keep my mind sharp to have to figure out the logic of the 'find' parameters each time! :-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Base directory, in CVS directory
Hi Noel, Short answer: Use "find ! -path '*/CVS/*'" (if you're using gnu find). Otherwise pipe the output of find through "grep -v '/CVS/' (you might have to backslash the '/'). ??? Answer to what question? I asked three: 1. Are there any other people with similiar opinion; 2. Are there any people with different opinion; 3. Is there any way to switch off that feature. The short answer to myself would be: 1. Yes. 2. Maybe. 3. No. But the long answer is interesting: Long answer: I've come to think that the Base subdirectory is a broken design. 1. The copy stored in Base isn't really the version that was originally checked out, it's the version existing at the time of "cvs edit". 2. "cvs unedit" is interactive due to it's modification check. As to "1" I think it is OK. I think I want it to restore to the same point as before "edit". Wouldn't change that. This way also "Edit works without the server connection" in a way. As to "2" I see no problem. The problem is to me something that cause the loss of work, like editing the wrong file. Not the case here. I propose to: 1. Have "cvs edit" create a backup of the file via the usual means (thereby exposing the backup -- not hiding it within CVS/Base). 2. Have "cvs unedit" solely unedit the file(s) (and perform notifications). "cvs unedit" would no longer unmodify the file(s) -- it would be up to the user to unmodify the file since he/she now knows where the backup is. 3. Get rid of Base (as it'll be unnecessary due to the previous). As for "1" I agree. Not quite sure about "2". Perhaps it could be smart enought to check for modifications and react properly(whatever 'properly' means). As for "3" I agree. Just wondering: Noel, do you have the access to the CVS repository? If you would/do, you could fix quite a lot of things there (and get your patches go thru, which would make CVS a much better tool :)... Just my two penny. Thanks you all for comments and advices. It helps :) BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks. __ Get Your Private, Free Email at http://www.hotmail.com
Re: Base directory, in CVS directory
[EMAIL PROTECTED] on 2000.04.08 20:11:12 But the long answer is interesting: Long answer: I've come to think that the Base subdirectory is a broken design. 1. The copy stored in Base isn't really the version that was originally checked out, it's the version existing at the time of "cvs edit". 2. "cvs unedit" is interactive due to it's modification check. As to "1" I think it is OK. I think I want it to restore to the same point as before "edit". Wouldn't change that. This way also "Edit works without the server connection" in a way. As to "2" I see no problem. The problem is to me something that cause the loss of work, like editing the wrong file. Not the case here. I guess the real problem I have with "Base" is its name. It's a misnomer. What's stored in it isn't a copy of the Base revision, but what existed at the time of "cvs edit". So, part of my proposal is to have "cvs edit" just create a backup the normal way CVS does with some other commands. The problem with an interactive "cvs unedit" is that "cvs release" is also interactive. Worse still, the interactiveness is per file. Sometimes I'd like to just wipe out an entire tree (somewhat like "rm -rf" with an unedit). I suppose I could just to "cvs unedit; rm -rf" but that takes forever. Also, being a Unix programmer, I don't like interactive tools (unless I make them interactive) -- I prefer Unix's "rm *" over DOS's "erase *". I propose to: 1. Have "cvs edit" create a backup of the file via the usual means (thereby exposing the backup -- not hiding it within CVS/Base). 2. Have "cvs unedit" solely unedit the file(s) (and perform notifications). "cvs unedit" would no longer unmodify the file(s) -- it would be up to the user to unmodify the file since he/she now knows where the backup is. 3. Get rid of Base (as it'll be unnecessary due to the previous). As for "1" I agree. Not quite sure about "2". Perhaps it could be smart enought to check for modifications and react properly(whatever 'properly' means). I should've been more specific here. My proposal is to have "cvs unedit" make the file read only, turn off the edit, and to notify other users. It will no longer unmodify the file. As for "3" I agree. Just wondering: Noel, do you have the access to the CVS repository? If you would/do, you could fix quite a lot of things there (and get your patches go thru, which would make CVS a much better tool :)... Although I think my CVS development skills have improved within the last year or so, I still have a bit to go (I haven't mastered sanity.sh, yet). So, in a way, I'm a little glad I don't have commit access to the CVS repository. I do wish, though, that someone is at least looking through my submissions to include what I think are the most important (ie "multiple edits per user per file" and "cvs edit -c" iff it works "correctly" when the server isn't active). Thanks for the vote of confidence, though. Noel
