Committing conflicts

[Martin Pool]

On Sat, May 31, 2008 at 11:00 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> I would hate to promise anything, but cp .bzr/checkout/conflicts might be a
> way
> to snapshot the state. And copying that into the next checkout would inform
> bzr
> that things are still conflicted.
>
> I won't promise anything, though, as touching things under .bzr/* is not
> generally recommended.

You can imagine a new format which has the conflict list under Ian's
proposed .bzrconf directory in the working tree.  Normally, before
committing the presence of a (semantically) non-empty file there would
cause the commit to abort but it could be forced.

This does definitely get into some of the problematic areas of having
control data in the working tree: what if the file itself conflicts,
what if people get a checkout in an older version that doesn't
understand that file, and so on.  And it wouldn't totally solve the
problem, because the .BASE etc files wouldn't be stored, we'd probably
commit as merged when it's not totally therefore later resolving the
conflict will be problematic.

-- 
Martin <http://launchpad.net/~mbp/>