Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gerhard Fiedler wrote: > - I cvs edit a file (but don't modify it). > - I cvs update it and the file gets updated by cvs and marked read-only. > - I then cvs unedit the file and cvs tells me that the file has been > modified and asks me whether I want to revert the changes. > > The strange thing is here that the file has been modified by cvs itself, > and only by cvs. Shouldn't cvs remember that, and know that the current > version in the sandbox is the unmodified (and at this point not even cvs > edited) version straight from the server? For there to be a new version it means someone else has modified the file. You have edited a version of the file, and now have a different version - you can only unedit (rollback) to the version you have edited. > After an update while the cvs edited flag was set but the file has not > actually been modified, the read-only flag has been reset and the cvs > edited flag, too. But the copy of the file in the CVS/Base folder is still > there. So even if the status of the file is not "cvs edited" anymore, cvs > allows an unedit and wants to revert to the outdated version of the file in > the CVS/Base folder. Read only doesn't mean a lot it's just a side-effect of the edit (in fact from some of the source comments it sounds like it was originally a bug but people got used to it working like that). update doesn't in general interact with the edit system. To make it do so is relatively complex (there's a solution in a comment in edit.c which involves the round trip of about 4 different requests per file... it's never been attempted as far as I know though). > I don't think this makes sense for any situation. Why revert to an outdated > revision? Because that's the version you originally edited. > Well, this is not what I experience. It happens also after a commit: if I > do a cvs unedit after a commit, I get the question whether I want to revert > the changes. If I say no, it just keeps asking me forever (or until I do > another edit). If I say yes, it reverts the just committed file to a > previous revision, and I have to cvs update it to get the one I just > committed. It won't unedit as there's no file to unedit to after a commit (unless you're trying to unedit on the other sandbox of course). I think the code should also be processing the Baserev file to do a full unedit but as it's never actually done that and it seems to work I'll leave it alone for now. > I may add that I'm using the same login from different sandboxes on > different systems. Does that make a difference? It seems so: Yes, because edits are (mostly) local to the sandbox. You're going to get into trouble trying to do two edits at the same time on a file. > It seems as if a part of the cvs edit functionality is handled on the > server on a per user basis, and another part of it is handled on the client > on a per sandbox basis, and thus using multiple sandboxes messes up this > logic between server and client. This would kind of make it impossible or > at least funky to correctly use multiple sandboxes -- which I have done so > far, and which is quite useful in many circumstances. It's always been like that - the edit/notify system is a bit strange and doesn't work like the rest of CVS. edit -c/commit -c helps as it enforces one edit per file which is mostly what's required. Tony