darcs

Issue 573 corrupted repository -- indelible "conflicting local changes"

Title corrupted repository -- indelible "conflicting local changes"
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, markstos, nejucomo, simonmar, thorkilnaur, tommy, zooko
Assigned To
Topics

Created on 2007-12-31.18:16:57 by zooko, last changed 2009-10-24.00:39:27 by admin.

Messages
msg2292 (view) Author: zooko Date: 2007-12-31.18:16:56
Folks:

This is a minor disaster for me, as the central, canonical, append- 
only repository of my company and my open source project, http:// 
allmydata.org , is corrupted in a way that will probably interfere  
with our operations.  So I will be grateful for any help.

I'm trying to reproduce the problem more precisely, but basically if  
I try to push a patch that updates the "install.html" file, I get:

------- begin included stdout/stderr
HACK wonwin-mcbrootles-computer:~/playground/allmydata/tahoe/trunk$  
time darcs push -v -v -v  zooko@dev.allmydata.com:/home/darcs/tahoe
We have the following patches to push:
Mon Dec 31 07:39:07 MST 2007  zooko@zooko.com
   * docs: even further simplify and reformat install.html

Mon Dec 31 07:39:07 MST 2007  zooko@zooko.com
   * docs: even further simplify and reformat install.html
Shall I push this patch? (1/1)  [ynWvpxqadjk], or ? for help: y

Fail: <stdin>: hGetChar: end of file

We have conflicts in the following files:
./install.html
You have conflicting local changes to:
./install.html
Proceed? [yn]sending 1 change to buildmaster:
  20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz
change sent successfully
Finished applying...

real    3m14.892s
user    0m0.417s
sys     0m0.171s

------- end included stdout/stderr

Note that this repository is set to reject pushes which cause  
conflicts, but despite that setting, it leaves unrecorded local  
changes in that repo after this.

I haven't so far reproduced this when pushing that same patch into an  
apparently identical repository on my local system.  I'm still trying  
to understand what is the difference between our central repo and  
this local copy.

You can probably see something about this problem for yourself by  
grepping for "install.html" in our patches:

http://allmydata.org/source/tahoe/trunk

Here are the grep results:

------- begin included output from 'grep "/install.html" in _patches'
_darcs/patches// 
20071230114717-92b7f-2055aaac4899f6389479880306906912b5de93fd.gz:addfile 
  ./install.html
_darcs/patches// 
20071230114717-92b7f-2055aaac4899f6389479880306906912b5de93fd.gz:move ./ 
install.html ./docs/install.html
_darcs/patches// 
20071230114717-92b7f-2055aaac4899f6389479880306906912b5de93fd.gz:hunk ./ 
docs/install.html 1
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 1
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 11
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 14
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 16
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 18
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 20
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 25
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 27
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 29
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 33
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 37
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 39
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 41
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 43
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 47
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 48
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 50
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 53
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 54
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 56
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 58
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 60
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 62
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 64
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 66
_darcs/patches//20071231020118-92b7f- 
de5d4867c89fc0f6f998cbc817e9bd2af2ab614e.gz:hunk ./docs/install.html 68
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 21
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 23
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 25
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 27
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 29
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 31
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 33
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 35
_darcs/patches// 
20071231143907-92b7f-421a25c32fcb3d15709673e54367c7b2050c3774.gz:hunk ./ 
docs/install.html 37
------- end included output from 'grep "/install.html" in _patches'

Regards,

Zooko
msg2293 (view) Author: zooko Date: 2007-12-31.21:53:37
Well, this is weird.  Taking this tarball:

https://zooko.com/buggydarcsrepo

and cd'ing into xyz/trunk, and running "darcs push -a ../central-on- 
dev" triggers this bug on one machine, but does not trigger it on  
another machine even though both are running darcs-1.0.9 release  
version.

Unfortunately, the machine where things work okay is not the central  
development machine for the project.  ;-/

Each darcs executable was compiled on that machine itself.

Could there be a bug in Haskell that would cause this sort of behavior?

Regards,

Zooko
msg2294 (view) Author: zooko Date: 2007-12-31.23:54:44
I built today's darcs stable on our development server and now when I  
run the test of pushing from "xyz/trunk" to "xyz/central-on-dev", the  
bug does not manifest itself.

Are the symptoms I reported suggestive of any known bug that was  
fixed between 1.0.9 release and today on the stable branch?

Regards,

Zooko
msg2308 (view) Author: tommy Date: 2008-01-02.18:05:17
I'm terribly not updated on darcs right now, but I believe there
are no (known) important bugs that can mess up a "push only"
repo. A quick search gives:

  Sun Jan 28 01:22:06 CET 2007  David Roundy <droundy@darcs.net>
    * fix bug triggered in replace.sh
    This bug was an annoying one that seemed to involve trouble caused by
    unsafeInterleaveIO and the order of evaluation, since we change the working
    directory.  I've simplified the code significantly.  Complicating the debug
    process was a race condition caused by the lack of --ignore-times in
    replace.sh, which was because darcs replace didn't accept that option.

Is it a replace patch that triggers the bug?

There are a few cases where 1.0.9 can produce garbage in
_darcs/patches/pending, but I don't think this can happen in a
push-only repo unless one runs 'darcs changes --look-for-adds'
AND have an un-added file in the repo.
msg2310 (view) Author: droundy Date: 2008-01-03.22:09:32
[helpful instructions snipped...]
> 
> Unfortunately, the machine where things work okay is not the central  
> development machine for the project.  ;-/

Alas, this is a most puzzling bug.  As you might imagine, I've been unable
to reproduce this.

Just to rule out some possibilities:

* Can you confirm that you actually untarred this on both machines, and ran
in that clean repo? (I'm wondering if timestamps or something
filesystem-specific might be playing a role here.)

* What happens if you add "apply --ignore-times" to the central repo where
this can be reproduced?

* Could you double-check (I looked in the tarball, but am trying to cover
bases here, since I'm confused) that the contents of _darcs/patches/pending
is either "{\n}\n" or empty?

* What sort of system is the system showing these symptoms? I'm thinking OS
and particularly whether it's running a 64 bit processor.  I don't see how
these would be relevant, but am grasping at straws here. Also, does the
other system--which doesn't display the bug--differ in any of these
regards? What ghc was used to compile darcs?
-- 
David Roundy
Department of Physics
Oregon State University
msg2314 (view) Author: zooko Date: 2008-01-04.21:51:41
Thanks for looking at this, David.

I'm busy on the imminent v0.7.0 release of our secure, decentralized  
filesystem, http://allmydata.org , so after this message I probably  
won't look at this more until next week.

On Jan 3, 2008, at 3:09 PM, David Roundy wrote:

> * Can you confirm that you actually untarred this on both machines,  
> and ran
> in that clean repo? (I'm wondering if timestamps or something
> filesystem-specific might be playing a role here.)

I'll try it again just to be sure...

<many minutes pass...>

Argh!  I can't reproduce it!

I retrieved the tarball that I made, put the same darcs executable  
back into my path, and then ran the same command, on the same  
computer, and this time I do not get the error.  8-(

I assure you that I was not hallucinating: I got the same behavior  
every time I tried it (on this computer, with this darcs executable),  
and so did my team-mates.

Okay, I really need to get back to work, but I thank you for your  
attention and apologize for not being able to reproduce it.  I will  
wrack my brain later to think of what could possibly have changed.

The problem went away when I built darcs 1.1.0pre on this computer  
(which required me to build a new ghc first), and then later it  
turned out that there was an incompatibility between the new 1.1.0pre  
and our version of the tailor tool, so I put the original darcs-1.0.9  
back.

A-ha!  Does darcs use ghc at runtime?  Because I upgraded ghc on this  
machine, and I did not put the old ghc back when I put the old darcs  
back...  No ldd tells me that there is nothing like that going on.   
<sigh>

Okay, more later,

Regards,

--Z

P.S.  In fact, we actually got the same error on a *different*  
computer, too -- our public development server, http:// 
allmydata.org ...  I'll go to that one and see if I can find evidence  
later...
msg2344 (view) Author: markstos Date: 2008-01-07.03:26:21
I'm changing the status to "Need example", since knowing more details about how
to  reproduce this seem critical to addressing it.  I'm particularly interested
to know if might also be "resolved in unstable".
msg2444 (view) Author: zooko Date: 2008-01-11.20:42:33
So fortunately for the prospects of making progress on this bug, but  
unfortunately for the prospects of the allmydata.org project  
continuing to use darcs, this bug just bit us again.

The first thing I need to do is work around it so that it doesn't  
impede my co-workers.  Then I will try to make it reproducible so  
that we can debug it.

First of all, I made "cp -a"'s of the three repos (on three different  
machines) where it happened.

Regards,

Zooko
msg2445 (view) Author: droundy Date: 2008-01-11.20:50:25
On Fri, Jan 11, 2008 at 12:39:13PM -0800, zooko wrote:
> So fortunately for the prospects of making progress on this bug, but  
> unfortunately for the prospects of the allmydata.org project  
> continuing to use darcs, this bug just bit us again.
> 
> The first thing I need to do is work around it so that it doesn't  
> impede my co-workers.  Then I will try to make it reproducible so  
> that we can debug it.
> 
> First of all, I made "cp -a"'s of the three repos (on three different  
> machines) where it happened.

Great! And thanks for your patience (which might perhaps be enforced).  Let
me know if there's any way I can help you work around it! (The one upside
here is that a hard-to-reproduce bug might be an easy-to-workaround bug...)
-- 
David Roundy
Department of Physics
Oregon State University
msg2447 (view) Author: zooko Date: 2008-01-11.23:27:34
Okay, here's what I know so far:

My coworker Rob wrote a patch on his Mac machine, using darcs 1.0.8  
from MacPorts.  This is the patch (visible on our trac+darcs): [1].

He pushed this patch to our dev.allmydata.com machine, which is Linux  
and is running darcs 1.0.9.  When he did that, the push silently  
succeeded, even though it left unrecorded changes in the target repo,  
which is something that is not supposed to happen since we haven't  
not configure it to allow pushing of conflicting patches.

Next, the dev.allmydata.com machine automatically pushed the patch to  
the allmydata.org machine, which is linux running 1.1.0pre (exact  
version appended [2]).  This caused the same unrecorded changes to  
appear in the allmydata.org repo, although again that repo is not  
configured to allow conflicting patches to be pushed into it.

Next, I pulled from the dev.allmydata.com repo to my local repo on my  
Mac, running darcs 1.0.9.  I got the same unrecorded changes in my  
repo after pulling.

Next, I made a cp -a of my repo, and then tarred and 7zipped it, but  
the resulting file was 28 million bytes.  So to save space, I did:

$ cp -a trunk-got-bad-stuff trunk-got-bad-stuff-then-uncompressed
$ cd trunk-got-bad-stuff-then-uncompressed
$ darcs optimize --uncompress
$ cd ..
$ darcs get trunk-got-bad-stuff-then-uncompress trunk-got-bad-stuff- 
then-uncompress-the-darcs-gotten
$ tar c trunk-got-bad-stuff-then-uncompressed-the-darcs-gotten/ | 7z  
a -si trunk-got-bad-stuff-then-uncompressed-the-darcs-gotten.tar.7z

This resulted in a 14 million byte file, which I uploaded to my web  
server:

https://zooko.com/trunk-got-bad-stuff-then-uncompressed-the-darcs- 
gotten.tar.7z

You can untar it with:

sudo apt-get install p7zip-full
7z e -so trunk-got-bad-stuff-then-uncompressed-the-darcs-gotten.tar. 
7z | tar x

If you can't untar that tarball, or if you can't detect a bug in that  
repo, then please ask me and I will be happy to help reproduce the bug.

Regards,

Zooko

[1] http://allmydata.org/trac/tahoe/changeset/1855
[2] allmydata.org: "darcs --exact-version | head":

darcs compiled on Dec 31 2007, at 14:52:29
# configured Mon Dec 31 14:55:48 PST 2007
./configure /usr/local/stow/darcs-1.1.0pre/share/config.site /usr/ 
local/stow/darcs-1.1.0pre/etc/config.site

Context:

[add some changelog entries
Tommy Pettersson <ptp@lysator.liu.se>**20071111204931]

[add "hidden" printer, for printing things to screen but not file.
msg2448 (view) Author: zooko Date: 2008-01-12.05:34:44
My brother Nejucomo just got a similar error -- pull silently  
succeeded and then left unrecorded changes -- on Ubuntu 7.04 with  
darcs 1.0.9rc2.  He had a much older version of our repository, and  
he pulled to become up to date with our current repository, but the  
unrecorded changes that he got were different than the other two that  
I've seen.  Also, happily, he made a "darcs get" copy of his  
repository before he pulled, so he should be able to reproduce this  
problem at will.

Stand by for a tarball of his repo from *before* he pulled.

--Z
msg2449 (view) Author: droundy Date: 2008-01-12.15:24:55
On Fri, Jan 11, 2008 at 11:27:35PM -0000, Zooko wrote:
> If you can't untar that tarball, or if you can't detect a bug in that  
> repo, then please ask me and I will be happy to help reproduce the bug.

I've got the tarball, but I'm not clear how to use it to reproduce the bug.
I don't see any problems there (e.g. no unrecorded changes), but I only
looked with the latest darcs-unstable and the darcs 1.0.9rc1 that is in
etch, so it may be that the bug appeared and disappeared between those
versions.

What should I see?
-- 
David Roundy
Department of Physics
Oregon State University
msg2450 (view) Author: zooko Date: 2008-01-12.16:22:05
>
> I've got the tarball, but I'm not clear how to use it to reproduce  
> the bug.
> I don't see any problems there (e.g. no unrecorded changes), but I  
> only
> looked with the latest darcs-unstable and the darcs 1.0.9rc1 that  
> is in
> etch, so it may be that the bug appeared and disappeared between those
> versions.
>
> What should I see?

I haven't tried to reproduce it yet, but if I did I guess I would  
obliterate the patch that Rob wrote on his Mac and then repull that  
patch.  Also, Nejucomo has a tarball from before he experienced the  
issue, so if you can get that tarball from him, then pull all patches  
into it from the Tahoe trunk, that might reproduce the bug.

More later!  (I'm on my way to the airport.)

--Z
msg2452 (view) Author: nejucomo Date: 2008-01-12.21:49:44
I'm sorry, I didn't realize this tarball is over 15 MB until I tried
sending email.  Is there another delivery method I could use?
(Perhaps I can post this tarball to the allmydata.org site somewhere?)

Nathan

---------- Forwarded message ----------
From: Nathan <nejucomo@gmail.com>
Date: Jan 12, 2008 1:31 PM
Subject: Re: [issue573] corrupted repository -- indelible "conflicting
local changes"
To: zooko <zooko@zooko.com>
Cc: Darcs bug tracker <bugs@darcs.net>, beschmi@cloaked.de,
darcs-devel@darcs.net, droundy@darcs.net, eric.kow@gmail.com,
mark@summersault.com, ptp@lysator.liu.se

Here's the process leading to the bug:

Directory A had an old checkout, and I wanted to test a new checkout
on my system.

Inside a new directory, B, I ran "darcs get /path/to/A".

Then inside B/C (where lived B/C/_darcs), I ran "darcs pull
http://url-to-tahoe".

The attached tarball is of directory A.  I have not tried to recreate the error.

Thanks for looking into this!

On Jan 12, 2008 8:18 AM, zooko <zooko@zooko.com> wrote:
> >
> > I've got the tarball, but I'm not clear how to use it to reproduce
> > the bug.
> > I don't see any problems there (e.g. no unrecorded changes), but I
> > only
> > looked with the latest darcs-unstable and the darcs 1.0.9rc1 that
> > is in
> > etch, so it may be that the bug appeared and disappeared between those
> > versions.
> >
> > What should I see?
>
> I haven't tried to reproduce it yet, but if I did I guess I would
> obliterate the patch that Rob wrote on his Mac and then repull that
> patch.  Also, Nejucomo has a tarball from before he experienced the
> issue, so if you can get that tarball from him, then pull all patches
> into it from the Tahoe trunk, that might reproduce the bug.
>
> More later!  (I'm on my way to the airport.)
>
> --Z
>
msg2453 (view) Author: tommy Date: 2008-01-12.21:50:48
I can reproduce this bug with darcs 1.0.9. The very current
(just did a push) darcs-stable 1.1.0pre doesn't trigger the bug.
I'll start a darcs Trackdown to see if that gives any easy
clues.
msg2454 (view) Author: tommy Date: 2008-01-12.22:00:08
Well, one easy starter is that it is _darcs/patches/pending
that's guilty. So here's the quick workaround (for push-only
repos):

  in the apply post-hook do "rm _darcs/patches/pending"

An alternative is to switch to the current darcs-stable, which I
believe is pretty much stable, and has been for long, only I
haven't got myself to release it yet. There are quite a few
changes to the UI that should be properly explained in the
changelog first.
msg2455 (view) Author: tommy Date: 2008-01-12.22:33:14
On Sat, Jan 12, 2008 at 10:00:10PM -0000, Tommy Pettersson wrote:
> An alternative is to switch to the current darcs-stable, which I

Darn, that is not true.

The bug is actually a known bug. A backport exists (which is why
I wrongly thought darcs-stable was ok, but I haven't pushed it
yet). The reason I haven't pushed the backport is (beside I
wasn't aware it could be triggered this way) it conflicts badly
with darcs-unstable, and the required conflict resolution is of
course even worse.

I think I'm ready to wrap up a release of 1.1.0 tomorrow (well
rc1, and make it final within a week), but I'm not sure that's a
good idea when everything is focused on darcs2.

Anyway, with the inclusion of this unpushed backported fix I
think 1.1.0 is really very stable. I've almost only pushed fixes
and trivial stuff of the darcs guts to it (and some incomplete
hashed-format stuff due to dependencies). It's the UI that has
the most changes.

On the other hand, darcs2 has the new GADT testing and better
unit testing, so darcs2 might already be even more safe with the
old repo format than darcs1, even without real world testing. By
looking at the reported bugs it has mostly been optimization
issues.
msg2458 (view) Author: zooko Date: 2008-01-13.01:38:44
On Jan 12, 2008, at 1:46 PM, Nathan wrote:

> I'm sorry, I didn't realize this tarball is over 15 MB until I tried
> sending email.  Is there another delivery method I could use?
> (Perhaps I can post this tarball to the allmydata.org site somewhere?)

How about https://zooko.com

--Z
msg2459 (view) Author: zooko Date: 2008-01-13.01:42:04
On Jan 12, 2008, at 2:33 PM, Tommy Pettersson wrote:

> On the other hand, darcs2 has the new GADT testing and better
> unit testing, so darcs2 might already be even more safe with the
> old repo format than darcs1, even without real world testing. By
> looking at the reported bugs it has mostly been optimization
> issues.

If you want my opinion, you should release darcs 1.1.0 and also darcs  
2.0preWhatever, and mention the latter in the release notes of the  
former, so people can try it out.

--Z
msg2495 (view) Author: droundy Date: 2008-01-14.22:25:15
On Jan 12, 2008 8:38 PM, zooko <zooko@zooko.com> wrote:
> On Jan 12, 2008, at 2:33 PM, Tommy Pettersson wrote:
> > On the other hand, darcs2 has the new GADT testing and better
> > unit testing, so darcs2 might already be even more safe with the
> > old repo format than darcs1, even without real world testing. By
> > looking at the reported bugs it has mostly been optimization
> > issues.
>
> If you want my opinion, you should release darcs 1.1.0 and also darcs
> 2.0preWhatever, and mention the latter in the release notes of the
> former, so people can try it out.

I'm right there with Zooko.  I'd say we should release darcs 1.1.0 (or
darcs 1.10.0?) now.  darcs2 still has a few known regressions, and
it's got a *huge* amount of new code in it.  As much as I'd like to
get more testers for darcs2, darcs1 is a better bet for those for whom
darcs already works fine, who are working on mission-critical
repositories, and who just want bugfixes (and 6.8 compatibility).

Unfortunately, the new GADT static checking doesn't (yet) extend over
all of darcs, so while it's been very useful, it doesn't help at all
with the high-level code that defines darcs commands.

David
msg2496 (view) Author: droundy Date: 2008-01-14.22:25:34
On Jan 12, 2008 8:38 PM, zooko <zooko@zooko.com> wrote:
> On Jan 12, 2008, at 2:33 PM, Tommy Pettersson wrote:
> > On the other hand, darcs2 has the new GADT testing and better
> > unit testing, so darcs2 might already be even more safe with the
> > old repo format than darcs1, even without real world testing. By
> > looking at the reported bugs it has mostly been optimization
> > issues.
>
> If you want my opinion, you should release darcs 1.1.0 and also darcs
> 2.0preWhatever, and mention the latter in the release notes of the
> former, so people can try it out.

I'm right there with Zooko.  I'd say we should release darcs 1.1.0 (or
darcs 1.10.0?) now.  darcs2 still has a few known regressions, and
it's got a *huge* amount of new code in it.  As much as I'd like to
get more testers for darcs2, darcs1 is a better bet for those for whom
darcs already works fine, who are working on mission-critical
repositories, and who just want bugfixes (and 6.8 compatibility).

Unfortunately, the new GADT static checking doesn't (yet) extend over
all of darcs, so while it's been very useful, it doesn't help at all
with the high-level code that defines darcs commands.

David
msg2497 (view) Author: daveroundy Date: 2008-01-14.22:29:37
Tommy, have you been able to check with darcs2? I imagine that it's
fixed there, if you backported the fix from unstable...

On Jan 12, 2008 4:50 PM, Tommy Pettersson <bugs@darcs.net> wrote:
> I can reproduce this bug with darcs 1.0.9. The very current
> (just did a push) darcs-stable 1.1.0pre doesn't trigger the bug.
> I'll start a darcs Trackdown to see if that gives any easy
> clues.
msg2498 (view) Author: daveroundy Date: 2008-01-14.22:29:45
Tommy, have you been able to check with darcs2? I imagine that it's
fixed there, if you backported the fix from unstable...

On Jan 12, 2008 4:50 PM, Tommy Pettersson <bugs@darcs.net> wrote:
> I can reproduce this bug with darcs 1.0.9. The very current
> (just did a push) darcs-stable 1.1.0pre doesn't trigger the bug.
> I'll start a darcs Trackdown to see if that gives any easy
> clues.
msg2508 (view) Author: tommy Date: 2008-01-14.23:41:43
On Mon, Jan 14, 2008 at 10:29:46PM -0000, David Roundy wrote:
> Tommy, have you been able to check with darcs2? I imagine that it's
> fixed there, if you backported the fix from unstable...

Yes, darcs2 worked fine on zooko's repo.

I'll see what I can do about 1.1.0.
msg2509 (view) Author: tommy Date: 2008-01-14.23:41:49
On Mon, Jan 14, 2008 at 10:29:46PM -0000, David Roundy wrote:
> Tommy, have you been able to check with darcs2? I imagine that it's
> fixed there, if you backported the fix from unstable...

Yes, darcs2 worked fine on zooko's repo.

I'll see what I can do about 1.1.0.
msg2514 (view) Author: simonmar Date: 2008-01-15.09:38:34
Tommy Pettersson wrote:
> Tommy Pettersson <ptp@lysator.liu.se> added the comment:
> 
> On Sat, Jan 12, 2008 at 10:00:10PM -0000, Tommy Pettersson wrote:
>> An alternative is to switch to the current darcs-stable, which I
> 
> Darn, that is not true.
> 
> The bug is actually a known bug. A backport exists (which is why
> I wrongly thought darcs-stable was ok, but I haven't pushed it
> yet). The reason I haven't pushed the backport is (beside I
> wasn't aware it could be triggered this way) it conflicts badly
> with darcs-unstable, and the required conflict resolution is of
> course even worse.
> 
> I think I'm ready to wrap up a release of 1.1.0 tomorrow (well
> rc1, and make it final within a week), but I'm not sure that's a
> good idea when everything is focused on darcs2.

I tried the latest darcs-stable recently on Windows, and had some problems. 
  Perhaps I missed something, but it seemed that 'darcs get --partial' was 
getting *all* the patches, ignoring the checkpoint.  And due to the known 
case-insensitive-filesystem issue that caused the get to fail.

I had to back off to 1.0.9 to get it to work again.  I still have the 
1.1.0pre binary if you need any more details, but perhaps the above will be 
enough to go on.

Cheers,
	Simon
msg2515 (view) Author: simonmar Date: 2008-01-15.09:38:45
Tommy Pettersson wrote:
> Tommy Pettersson <ptp@lysator.liu.se> added the comment:
> 
> On Sat, Jan 12, 2008 at 10:00:10PM -0000, Tommy Pettersson wrote:
>> An alternative is to switch to the current darcs-stable, which I
> 
> Darn, that is not true.
> 
> The bug is actually a known bug. A backport exists (which is why
> I wrongly thought darcs-stable was ok, but I haven't pushed it
> yet). The reason I haven't pushed the backport is (beside I
> wasn't aware it could be triggered this way) it conflicts badly
> with darcs-unstable, and the required conflict resolution is of
> course even worse.
> 
> I think I'm ready to wrap up a release of 1.1.0 tomorrow (well
> rc1, and make it final within a week), but I'm not sure that's a
> good idea when everything is focused on darcs2.

I tried the latest darcs-stable recently on Windows, and had some problems. 
  Perhaps I missed something, but it seemed that 'darcs get --partial' was 
getting *all* the patches, ignoring the checkpoint.  And due to the known 
case-insensitive-filesystem issue that caused the get to fail.

I had to back off to 1.0.9 to get it to work again.  I still have the 
1.1.0pre binary if you need any more details, but perhaps the above will be 
enough to go on.

Cheers,
	Simon
msg3491 (view) Author: markstos Date: 2008-02-16.04:07:09
From reading this bug history, it is "resolved-in-unstable", and Tommy is in the
process of porting this fix to darcs-stable, so that it can be resolved there, too.
History
Date User Action Args
2007-12-31 18:16:59zookocreate
2007-12-31 21:53:39zookosetstatus: unread -> unknown
nosy: + darcs-devel
messages: + msg2293
2007-12-31 23:54:45zookosetmessages: + msg2294
2008-01-02 18:05:18tommysetmessages: + msg2308
2008-01-03 22:09:34droundysetmessages: + msg2310
2008-01-04 21:51:42zookosetmessages: + msg2314
2008-01-05 15:13:53droundysetstatus: unknown -> deferred
2008-01-07 03:26:22markstossetstatus: deferred -> waiting-for
nosy: + markstos
messages: + msg2344
2008-01-11 20:42:34zookosetnosy: markstos, droundy, tommy, darcs-devel, beschmi, kowey, zooko
messages: + msg2444
2008-01-11 20:50:26droundysetmessages: + msg2445
2008-01-11 23:27:35zookosetmessages: + msg2447
2008-01-12 05:34:46zookosetnosy: + nejucomo
messages: + msg2448
2008-01-12 15:24:57droundysetnosy: markstos, droundy, tommy, darcs-devel, beschmi, kowey, zooko, nejucomo
messages: + msg2449
2008-01-12 16:22:06zookosetmessages: + msg2450
2008-01-12 21:49:46nejucomosetmessages: + msg2452
2008-01-12 21:50:49tommysetmessages: + msg2453
2008-01-12 22:00:10tommysetmessages: + msg2454
2008-01-12 22:33:16tommysetmessages: + msg2455
2008-01-13 01:38:46zookosetmessages: + msg2458
2008-01-13 01:42:06zookosetmessages: + msg2459
2008-01-14 22:25:21droundysetmessages: + msg2495
2008-01-14 22:25:35droundysetmessages: + msg2496
2008-01-14 22:29:42daveroundysetnosy: + daveroundy
messages: + msg2497
2008-01-14 22:29:47daveroundysetmessages: + msg2498
2008-01-14 23:41:45tommysetmessages: + msg2508
2008-01-14 23:41:51tommysetmessages: + msg2509
2008-01-15 09:38:37simonmarhaskellsetnosy: + simonmarhaskell
messages: + msg2514
2008-01-15 09:38:46simonmarhaskellsetmessages: + msg2515
2008-02-16 04:07:10markstossetstatus: waiting-for -> resolved-in-unstable
nosy: droundy, tommy, beschmi, kowey, markstos, darcs-devel, zooko, nejucomo, simonmarhaskell, daveroundy
messages: + msg3491
2008-09-04 21:31:46adminsetstatus: resolved-in-unstable -> resolved
nosy: + dagit
2008-09-28 20:49:40adminsetnosy: + thorkilnaur, simon, - daveroundy
2009-08-06 17:41:35adminsetnosy: + jast, Serware, dmitry.kurochkin, mornfall, - droundy, nejucomo, simonmarhaskell
2009-08-06 20:38:51adminsetnosy: - beschmi
2009-08-10 22:10:10adminsetnosy: + simonmarhaskell, nejucomo, - jast, Serware, mornfall
2009-08-11 00:04:09adminsetnosy: - dagit
2009-08-25 17:26:18adminsetnosy: - simon
2009-08-27 14:07:53adminsetnosy: tommy, kowey, markstos, darcs-devel, zooko, nejucomo, simonmarhaskell, thorkilnaur, dmitry.kurochkin
2009-10-24 00:39:27adminsetnosy: + simonmar, - simonmarhaskell