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.
Tony Hoyle wrote: > 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. 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 kinds of Entries manipulation or just when adding or removing files to/from it? From my observations I think the latter is the case but so far I haven't been able to determine what triggers the resync between Entries.Log and Entries that ultimately results in the removal of Entries.Log. AFAICT it doesn't seem to happen awfully often. Thus, if I just aborted whenever an Entries.Log was present I don't think I would get very much done at all... so, what I was trying to get at with my question was whether merges are maybe one of the actions that trigger the Entries.Log>Entries resync so I effectively wouldn't have to look at it... am I getting any clearer? > 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. I will definitely add the check for Entries.Backup. > >> If there's a way to do this without hacking the ./CVS/Entries file > it >> would sure be preferable... > > Not without doing a commit... 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)? > >> - 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. Here's the regexp I'm using to identify conflict markers at the moment: (?ms)^<<<<<<< [^\n]*\n.*=======\n.*>>>>>>> [\d\.]*$ 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? > >> - 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. Yes, I just wanted to let this stick out a bit. Currently I'm replacing the "Result of merge" with "Resolved". Ideally all of this shouldn't be necessary at all, as WinCvs should probably just treat "Resolved" as a distinct state, effectively rendering the current "Conflict" file status as a non-committable state. I just filed an RFE about this (#823388): http://tinyurl.com/qv9i > 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. You mean the markers in Entries? See above for how I'm checking for conflict markers in the files themselves at the moment. How does the update command perform the check? I noticed that making arbitrary modifications alone does not suffice to make it report the file as merely modified instead of in conflict. It only does so if I really remove the conflict markers from the file itself. Cheers, -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)