I just tried again to convert a conflictful darcs 1 repo so I and work
colleagues can enter the brave new world of darcs 2. I had a less than optimal
experience.

- It's on an ubuntu dapper server, so I downloaded the darcs 2.0.2 tarball and
built that with ubuntu's ghc 6.4. I advocated dropping 6.4 support so I can't
complain too loudly here. I will need to build a newer ghc so I can build latest
darcs though, since I've run into darcs bugs.

- I haven't see it clearly stated that converting a darcs 1 repo can be lossy.
This is a little disappointing. 

- I wasn't sure what these lossy warnings meant in practice and how to react to
them. If I get the conversion to complete I guess I'll be recursive-diffing the
two repos and applying fixup patches.

In april I asked: what is the significance of many "lossy conversion of
complicated conflict:" warnings during conversion to darcs-2 ?
and lispy replied: I think only droundy could answer that.  My guess is that
something about the way complicated conflictors are "reduced" or "removed" leads
to a lossy conversion.

I think the manual needs much more real-world info for darcs convert, since we
want the world to move off darcs-1 format.

- converting this particular repo gives about 8 lossy warnings and then segfaults.

- when I try to strace the darcs convert command, my shell terminates.

The repo can't easily be made public. Suggestions welcome!

Convert warnings log uploaded.

Attachments

• convert.log

cf issue983

I do some guessing here, but the way I have understood it the
lossynes is in the nesting of old-format mergers. If my
understanding is right, the only practical losses will be some
tags.

Here's how I think it works. The old-format mergers contains all
possible conflicting commutation paths (in a nested manner), so
they can be commuted back with any of the involved conflicting
patches (given enough time). The new mergers are always flat, so
they don't grow exponentially. The conversion therefore has to
flatten nested mergers, and this may lose information so that
the converted merger can no longer be commuted back with some of
the conflicting patches that caused it. This is effectively the
same as introducing some new dependencies between the patches.
What these dependencies will be depends on the order of the
patches in the converted repository's inventory, so different
versions of the same repository will get different dependencies,
and become incompatible. I think it could happen that a patch
tagged by some tag can become dependent on a patch that is not
in that tag, which would make the tag irretrievable.

Hopefully someone can confirm or deny some of this, so it can go
in the manual.

For what it's worth, I think it would be ideal (but not critical) to have this
sorted in the UI and/or manual before the 2.1.0 release comes out.

I'm tacking David on to this bug because he really is the best person to explain
what 'lossy' means here or if Tommy's explanation is right.

Also, as I understand it, our representation of conflicts is still nested and
can still grow exponentially.  It's just a lot flatter and less likely to do so
in the kinds of cases that users have typically faced.  You can still trigger a
blow up by starting a conflict fight (i.e. where your conflict resolution itself
conflicts).  Thankfully, this is a relatively well-understood problem (we know
how to avoid it in practice), and a rarer case than just, say, deleting a file
and pulling in a lot of changes that affect it.

I was searching for an explanation on this today, and I found this bit from
issue256 by David:

> Alas, running convert on two related repositories will usually result in
> corruption, so this is not a good test.  This is because convert "flattens"
> conflicts, converting them into ordinary non-conflicting patches, and the
> result of this flattening depends on the repository state (and the order of
> patches in a repository).  I think this is adequate, because the conversion
> need only be done once, and is not urgent.  But the result is that it is
> very hard (or impossible?) to convert two repositories such as these and
> see if the "same" repositories exhibit a bug in darcs-2.

So I suppose this is what the lossy conversion warnings mean?  Some conflicts
are simplified so that inner conflicts are wiped away and replaced with
non-conflicting patches?  David,  if you have a moment, could you confirm?

I would like to write this as an FAQ entry:  Why do I get a lossy conversion
warning when I run darcs convert?

Yes, Eric, that's right.

Do people feel that this has been adequately addressed by my documentation
patches (as as 2.2.0pre2)?  If not, what additional points should I cover?

I think the manual should still say a word about lossy conversion warnings.

Right now ``darcs help convert`` about what the convert command does,
what the consequences of running it are and how to go about it.  

To polish it off, we just need a word about why "lossy conversion"
warnings get printed out and what it means for the user (no longer be
able to retrieve both sides of the conflict).

Say you have patch X and you want to pull patch Y on top of it (but X
and Y conflict).  The net result after all the inverse and commutation
dance is done is that your "Y" patch is a merger which (a) notes down X
and Y (b) has the effect -X.  From the user point of view, lossy
conversions mean that they no longer see the Y that they pulled, just
the -X on top of their X.

I think it's safe to just make a first stab explaining what lossy
conversions mean for the user and have a patch theory geek review it.

I'm making Ganesh nosy to this documentation ticket because of issue1809
(which may make conversions less lossy)