At 09:07 2003-10-29 -0800, Mark D. Baushke wrote:
>
>It is not up to cvs to determine what data patterns should or should not
>be allowed to be committed into a file.
>
Indeed, I routinely commit conflicted files after applying vendor
updates. Tag this state (with log messages distinguishing conf
Thank you for the advice about commitinfo. I believe we will do exactly
that as a safeguard against future problems.
I totally respect that CVS should be content agnostic, although I did have
to rename my "cvs" java package to "cvsutil" because you can't have dirs
named "cvs" in the repository.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood <[EMAIL PROTECTED]> writes:
> I just found that one of the developers here has managed to commit a file
> with a conflict in it.
>
> I had been under the impression, based on documentation and past
> experience, that it was impossible to
Thank you! This is very helpful in reconstructing what happened.
[EMAIL PROTECTED] (Larry Jones) wrote on 10/29/2003 11:40:51 AM:
> David Wood writes:
> >
> > Are my assumptions about this mistaken? What circumstances allow
> > unresolved conflicts to be committed back to the repository?
>
> I
David Wood writes:
>
> Are my assumptions about this mistaken? What circumstances allow
> unresolved conflicts to be committed back to the repository?
If CVS had detected a conflict (which is recorded in the CVS/Entries
file) and the file has not been modified, CVS will not allow the commit.
If
I just found that one of the developers here has managed to commit a file
with a conflict in it.
I had been under the impression, based on documentation and past
experience, that it was impossible to commit a file with conflict markers
inside it. However, I just witnessed this.
Are my assumpti
