[cvsnt] Re: edit/commit/unedit problem

[Gerhard Fiedler]

>>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