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 11:50:16 +0000 (UTC), "Oliver Giesen" <ogware at gmx.net> wrote: >I bascially got the thing ready now and it seems to work nicely. > >One more thing though: would I have to look into Entries.Log as well or >could I rely on conflict files always being in Entries already? When >exactly is Entries.Log used? > Entries.Log is used for rollback in case of a crash - if it exists cvs replays the log file on the entries file before opening it. Entries.Backup is the new entries file that is written and renamed on top of the old Entries file. CVS prefers to use the Entries.Log to recover rather than rely on the Entries.Backup which may be partially written. If either Entries.Log or entries.Backup exist then it's probably not safe to start modifying Entries. >> If there's a way to do this without hacking the ./CVS/Entries file it >> would sure be preferable... Not without doing a commit... > >> - scan the specified file for conflict markers Also check the date here - an unmodified file is definately still a conflict. A modified file with conflict markers might be a false positive. >> - if none are found, remove the timestamp from the corresponding line >> in ./CVS/Entries, maybe even replacing the "Result of merge" with >> something like "Resolved" or something like that. It's sufficient to remove the '+comment' bit from the timestamp, which is the conflict marker that WinCVS uses. Be warned however that CVSNT also uses this info to stop you committing unchanged files with conflicts in them - it forces you to resolve the conflicts first. Make sure the markers aren't removed without thorough checking. Tony