[cvsnt] Re: edit/commit/unedit problem

[Tony Hoyle]

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