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