Impossible to resolve conflict

[vila]

>>>>> Steve Franks <bahamasfranks at gmail.com> writes:

    > Looks like I did a global/top-level add in a tree that had a
    > conflict,

Unless you did a 'bzr resolve --all' before 'bzr add', files generated
by bzr to help conflict resolution cannot be versioned, there is safe
guard.

    > only the files aren't actually there anymore.

That would make it harder to understand what happened.

    > I have to say, bzr's conflict resolution infrastructure is
    > **highly inefficient** compared to cvs!

May I suggest that something goes wrong in your case ? The general
feedback regarding CVS and its merge support is not inline with your
experience.

    > I suppose it's trying to be extra safe in some way?  I like the
    > fact that I haven't corrupted a binary file since I switched, but
    > I haven't achieved an efficient workflow yet, either.

Let's try to find where this went wrong then.

    > In cvs you just edited and committed, and no more conflict,

Right, but apparently you didn't do that either with bzr, given the
output of 'bzr status' you probably did something like:

  bzr merge from-somewhere

hmm, there are conflicts 
<unknown action enough to allow another merge, presumably 'bzr resolve --all'>

  bzr merge from-somewhere

damn, more conflicts

    > there was no dropping to the command line and typing in really
    > long file names manually, deleting files, cut & paste, etc.

For 'Text Conflict's, the only ones generated by CVS, bzr have the same
workflow, except you have to inform bzr when the conflicts are resolved
by doing:

  bzr resolve <file>

for each file in conflict

or

  bzr resolve

which will mark all Text Conflicts as resolved if no conflict markers
are left in the files (i.e. the user *did* remove them, resolving the
conflicts by editing the files).

    > I feel like a real 'hacker' now with all the files I've been
    > 'hacking' up.  Plus the whole tree is locked from committing, not
    > just the one file.

Right, that's a fundamental difference between bzr and CVS:
modifications rarely occur in a single file, so the whole tree has to be
committed at once to ensure that the resulting tree state is coherent
(say you create a new function in C with the prototype in the .h file
and the implementation in the .c file, committing only a single file
doesn't make sense).

    > I understand the benefits of having an atomic commit to a whole
    > tree, but locking it out when there's a conflict!? 

It's not locked, but you can't commit a tree with conflicts in it,
especially if some files contain conflict markers which can lead to,
say, compilation errors.

    > I'm stuck.  I'm going to wind up emailing files back and forth
    > between systems until I get this fixed...as usual...


    > ...(I suppose I could blow away the repository and start with a fresh
    > one, but that seems like a total cop-out, not to mention a couple gigs
    > still takes a long time over DSL)....

This sounds extreme to say the least.

    > [steve at fyre /usr/home/steve/projects]$ bzr status
    > modified:
    >   ZongeHoursFranks.gnumeric.xml
    > conflicts:
    >   Conflict adding file ZongeHoursFranks.gnumeric.xml.BASE.  Moved
    > existing file to ZongeHoursFranks.gnumeric.xml.BASE.moved.

Right, this is typical of an operation done on a tree where conflicts
weren't resolved.

bzr tries to minimize conflict generation, but when it does generate
one, it's because it can't decide automatically, it needs to be told.

If you don't tell it and instead continue to use a tree containing
conflicts, you will rarely get rid of conflicts (if ever).

There is certainly a weak spot in bzr here and this kind of operation
should just be forbidden by default, we're already  discussing it.

Now, based on your 'bzr status' output above, there is only one modified
file so you can restore your working tree by doing:

cp ZongeHoursFranks.gnumeric.xml keep-it-safe
bzr revert 
cp keep-it-safe HoursFranks.gnumeric.xml

and look into HoursFranks.gnumeric.xml to resolve conflicts.

Note that 'bzr revert' will forget about whatever 'bzr merge' you have
issued since your last commit.

       Vincent

--455C7180AAF.1292922462/axe--