[cvsnt] Unable to resolve merge conflicts
Gerhard Fiedler
lists at connectionbrazil.com
Tue Aug 1 13:58:20 BST 2006
Tony Eva wrote:
> and the only way I can find out if a conflict has been
> resolved is either to grep for the conflict markers (blech)
Why is that "blech"? I run a grep and get a list with all the files that
contain conflict markers. That's just as quick and convenient as running
WinCvs and looking at the file listing.
> IMHO again, since CVSNT knows that the conflict is resolved, it should
> tell me somehow (like changing the status, as CVS does).
Maybe it's because I'm used to it, but I don't think that cvs(nt) has much
of a chance of knowing when I resolved a conflict. Not even removing the
conflict markers is a good indicator. (The conflicts that are shown within
the conflict markers are the easy ones... :)
> Like you, I sometimes leave conflicts for later resolution; and sometimes
> I have to leave the resolution half-finished and resume it later. It's
> *really* annoying that I can't come back and easily see which files I've
> sorted out and which I haven't.
I always keep the merge logs around until everything is merged and tested
and committed. That helps. (It also helps that the WinCvs output copies as
RTF.) And then there's of course grep :) Seriously, what's the blech in
that?
It seems to me that the way you say cvs works wouldn't help you with
leaving a resolution half-finished. The moment you save the file, the
conflict marker is gone (you said), and you need to use some other method
to keep track of those files. So you need to have some other method, even
with cvs -- it seems.
I generally commit a merge as a whole, so I've never had that
multiple-commit issue you are talking about. I also don't work with commit
ids, I use tags when I need to mark a consistent state, so I wouldn't have
it even if I did use multiple commits.
Being able to run an update command that resets the conflict status seems
to be a useful thing, though.
Gerhard
More information about the cvsnt
mailing list