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

Oliver Giesen ogware at gmx.net
Tue Oct 14 14:36:45 BST 2003


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)


More information about the cvsnt mailing list