ati@ed101:/tmp/ucw_ajax.clean$ darcs pull --no-set-default ../ucw_dev.clean
darcs-bin: bug in get_extra commuting patch:
Thu Aug 10 00:55:57 CEST 2006  attila.lendvai@gmail.com
  * Refactored checkbox-field to use a hidden input and do not clear its value
at render-time
ati@ed101:/tmp/ucw_ajax.clean$

so, the strange(?) thing is this: i've got two official remote branches, and
clean copies of them locally, so 4 repos. i have optimized the official ones,
and continued pulling into the local ones. then i tried bulling between the
local ones when the error happened... 

after clean darcs get-ing the official repos the pull between the two doesn't
fail. the official repos are available at: http://common-lisp.net/project/ucw/repos/

hth, 

- attila

Hi,

Thanks, especially for giving us an example repo to play with.  Merging with
issue175.

attila,

Thanks for the report. 

The example repos you provided where very helpful. Using darcs 1.0.9, I was able
to reproduce the bug as you submitted it. 

I then used Darcs 2.0.0pre2 and ran "darcs convert" on your repositories and
tried again. The result was that it still failed:

$ darcs pull ../ucw_dev.clean_0
Pulling from "../ucw_dev.clean_0"...
darcs: bug in get_extra commuting patch:
Sat Jul 15 07:39:27 EDT 2006  attila.lendvai@gmail.com
  * Added render-widget-wrapper

####

It appears this bug still needs attention.

On Fri, Jan 11, 2008 at 04:43:15AM -0000, Mark Stosberg wrote:
> The example repos you provided where very helpful. Using darcs 1.0.9, I was able
> to reproduce the bug as you submitted it. 
> 
> I then used Darcs 2.0.0pre2 and ran "darcs convert" on your repositories and
> tried again. The result was that it still failed:

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.

It would be possible to write a more faithful conversion, but such a
conversion would need to fail in the presence of "doppleganger" patches,
because the semantics of darcs-2 differs in such cases from that of
darcs-1, and as a result there is no direct conversion of such changes.
I'm not sure that it's worth the effort to write a trickier converter,
given this caveat (particularly as it might be tricky to recognize the
presence of this situation).
-- 
David Roundy
Department of Physics
Oregon State University

David Roundy wrote:
>
>> I then used Darcs 2.0.0pre2 and ran "darcs convert" on your repositories and
>> tried again. The result was that it still failed:
> 
> 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.

Thanks for the clarification David.

Would it be useful in this case to convert just the target repo to the 
"hashed" format, (or even the the "darcs-2" format), and then test for 
the bug?

    Mark

On Fri, Jan 11, 2008 at 04:46:13PM -0000, Mark Stosberg wrote:
> David Roundy wrote:
> > 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.
> 
> Thanks for the clarification David.
> 
> Would it be useful in this case to convert just the target repo to the 
> "hashed" format, (or even the the "darcs-2" format), and then test for 
> the bug?

I don't think so.  The bug should still manifest itself, as the hashed
format doesn't change the merge semantics.  I'm afraid we'll have to either
write a trickier convert or restrict ourselves to testing the new semantics
on fresh repositories.  :(
-- 
David Roundy
Department of Physics
Oregon State University

>> Would it be useful in this case to convert just the target repo to the 
>> "hashed" format, (or even the the "darcs-2" format), and then test for 
>> the bug?
> 
> I don't think so.  The bug should still manifest itself, as the hashed
> format doesn't change the merge semantics.  I'm afraid we'll have to either
> write a trickier convert or restrict ourselves to testing the new semantics
> on fresh repositories.  :(

Thanks for the continued clarification, David.

A final question:

If we can confirm this issue is resolved when starting fresh with 
darcs-2 repositories, do we will want to consider the bug "resolved", 
even though it's potentially takes some kind of manual correction for a 
darcs 1.x set of repos to get a place where they all safely be converted 
to darcs-2.x?

Given the limited resources of project, that seems acceptable to me.
Perhaps instead of writing a trickier converter, we could make it easier 
for people how get this error to find some documentation to follow which 
describes a process to get their repos into a stable state, and then 
convert them to darcs-2 to avoid the issue in the future.

    Mark

On Fri, Jan 11, 2008 at 05:30:32PM -0000, Mark Stosberg wrote:
> A final question:
> 
> If we can confirm this issue is resolved when starting fresh with 
> darcs-2 repositories, do we will want to consider the bug "resolved", 
> even though it's potentially takes some kind of manual correction for a 
> darcs 1.x set of repos to get a place where they all safely be converted 
> to darcs-2.x?

Well, currently the conversion to darcs-2 requires a bottleneck, in which
only *one* repository is converted (i.e. all other branches get lopped
off).  I think this is reasonable, as the transition to darcs-2 is always
going to require a "flag day" in any case, when a project switches
repository format, and I haven't been able to come up with a realistic
scenario in which this would pose a real problem.

> Perhaps instead of writing a trickier converter, we could make it easier 
> for people how get this error to find some documentation to follow which 
> describes a process to get their repos into a stable state, and then 
> convert them to darcs-2 to avoid the issue in the future.

Yes, I think this is reasonable.  The primary motivation (in my mind) for
the trickier converter would be for quality-control purposes, to allow us
to generate more test cases to verify that the new code actually works.  A
friendlier conversion for our users would just be a side benefit. 
-- 
David Roundy
Department of Physics
Oregon State University

On Fri, Jan 11, 2008 at 08:43:13PM +0200, Tristan Seligmann wrote:
> * David Roundy <droundy@darcs.net> [2008-01-11 12:42:31 -0500]:
> > Well, currently the conversion to darcs-2 requires a bottleneck, in which
> > only *one* repository is converted (i.e. all other branches get lopped
> > off).  I think this is reasonable, as the transition to darcs-2 is always
> > going to require a "flag day" in any case, when a project switches
> > repository format, and I haven't been able to come up with a realistic
> > scenario in which this would pose a real problem.
> 
> On some of my projects we have long-running branches that are never
> merged back into the "mainline" (although changes from the mainline are
> pushed out to these branches); this isn't an issue for me anymore,
> because these projects will have been retired before darcs-2 is even
> released, but perhaps other people have this kind of workflow.

As long as there's only one such branch, there's no problem (unless there
are conflicts): you just convert that branch, and then reconstruct mainline
by obliterating all the patches that shouldn't be there.
-- 
David Roundy
Department of Physics
Oregon State University

* David Roundy <droundy@darcs.net> [2008-01-11 12:42:31 -0500]:

> Well, currently the conversion to darcs-2 requires a bottleneck, in which
> only *one* repository is converted (i.e. all other branches get lopped
> off).  I think this is reasonable, as the transition to darcs-2 is always
> going to require a "flag day" in any case, when a project switches
> repository format, and I haven't been able to come up with a realistic
> scenario in which this would pose a real problem.

On some of my projects we have long-running branches that are never
merged back into the "mainline" (although changes from the mainline are
pushed out to these branches); this isn't an issue for me anymore,
because these projects will have been retired before darcs-2 is even
released, but perhaps other people have this kind of workflow.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

* David Roundy <droundy@darcs.net> [2008-01-11 12:42:31 -0500]:

> Well, currently the conversion to darcs-2 requires a bottleneck, in which
> only *one* repository is converted (i.e. all other branches get lopped
> off).  I think this is reasonable, as the transition to darcs-2 is always
> going to require a "flag day" in any case, when a project switches
> repository format, and I haven't been able to come up with a realistic
> scenario in which this would pose a real problem.

On some of my projects we have long-running branches that are never
merged back into the "mainline" (although changes from the mainline are
pushed out to these branches); this isn't an issue for me anymore,
because these projects will have been retired before darcs-2 is even
released, but perhaps other people have this kind of workflow.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Per David's comments, this is considered "resolved-in-unstable", although it can
still be triggered with darcs-2 when run against repos that were originally
created with darcs 1 and the old repo format.