[cvsnt] Re: resolving conflicts before committing...

[Tony Hoyle]

On Tue, 14 Oct 2003 13:36:45 +0000 (UTC), "Oliver Giesen"
<ogware at gmx.net> wrote:

>Yes, I am aware of how to interpret Entries.Log . It's just that I
>found that I've got quite a lot of them in my sandboxes even though I
>don't remember any crashes. So, is it that Entries.Log is used for all

Entries.Log is removed at the same time that the Entries file is
created.  When cvs first opens the Entries it looks for the
Entries.Log and replays it.  I'm not sure why there are some left
around somtimes... I've seen it too but it doesn't seem to break
anything so it's probably always done that.

>I noticed that upon doing an Update on a resolved file the reported
>state changes from C to M (although Status still reports the file to
>have conflicts). Wouldn't it make sense if the client also adjusted the
>Entries file at that point (or whatever drives the Status output)?

Until the file is committed it still has conflicts.  Even if you
update and new information is added, the old conflicts are considered
to be still there unless you've successfully committed a revision
without them.  Normally you don't update on a merged file, though.

>Do you think I should treat a file that doesn't return a match for this
>as unresolved (if the timestamp hasn't changed)? I guess it wouldn't be
>committable anyway, so that's probably reasonable. OTOH, how DO I
>resolve such a file? If there are no conflict markers there isn't
>really anything to do, is there?

You can commit a file with conflict markers in it (because of the risk
of false positives) although you'll get a warning.  You can't commit a
'conflicting' file whose timestamp has not changed since it was
checked out, because it's clearly not been edited since the conflict
occurred.

Tony