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.
>>I'm having a problem with the edit/commit/unedit sequence (and possibly the >>edit/update/unedit sequence). Quite often (but it seems not always) the >>following happens: >> >>- I do an edit on a file >>- I modify it and commit it (or I don't modify it, but an update modifies >>it) >>- On a subsequent unedit I get the message that the file has been modified >>and it asks me whether I want to revert. >> >>If I revert, it gets reverted to a previous revision and I need to update >>the file to get the HEAD revision (that I committed immediately before the >>unedit, or that I already got through the update preceding the unedit). If >>I don't revert, the file doesn't get unedited (at least not in the >>sandbox). >> > If an update modifies it this is correct - you have done an 'edit' on > a particular revision of a file, and you no longer have that file in > your sandbox, meaning someone else has committed a revision during > your edit. You have 3 choices - 1. don't unedit, 2. unedit and keep > the revision you started with (then commit it), 3. unedit and keep the > new revision. [After I wrote the immediate following, it occurred to me that the fact that I'm working from two different sandboxes with the same login may have to do with the problem. Please see a description of one of the effects of this below towards the end of the message.] I guess I don't understand you. Here is what happens with the update scenario: - 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? It seems cvs has two conflicting notions of the cvs edited status: the one that's expressed by the read-only flag (that's maintained exclusively by cvs in this scenario) and the one that probably is a backup copy of the cvs edited file. 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. I don't think this makes sense for any situation. Why revert to an outdated revision? > If you're using edit in this way you should make sure that everyone > else is also using edit, otherwise it won't work. Otherwise just > don't bother with edit as it's not giving you any advantage. This is especially important with binary files. Otherwise the communication overhead is just too big. The edit/unedit feature provides the necessary synchronization. > commit will automatically unedit (actually it removes the base > revision - not sure how that achieves unedit myself but it's always > worked like that so I assume it works). 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. -------------------------------------- I may add that I'm using the same login from different sandboxes on different systems. Does that make a difference? It seems so: - I cvs edit a file on the 1st system (and sandbox). - I do the same on a 2nd system, and get a message that the file is being edited by me on the 1st system. - I cvs unedit on the 2nd system. - I cvs edit again on the 2nd system, but from this point on I don't get a message anymore that the file is being edited on the 1st system. It seems as if the unedit from the 2nd system had canceled the edit flag on the server, also for the 1st system -- but the sandbox on the 1st system is still thinking that the file is marked as "edit" on the server. I'm not sure about the implications of this getting out of sync of the 1st sandbox. 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. Is this by design? I thought the idea of working with multiple sandboxes was an integral part of the design of cvs. Thanks, Gerhard