Created on 2007-12-31.18:16:57 by zooko, last changed 2009-10-24.00:39:27 by admin.
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.
|
|
Date |
User |
Action |
Args |
2007-12-31 18:16:59 | zooko | create | |
2007-12-31 21:53:39 | zooko | set | status: unread -> unknown nosy:
+ darcs-devel messages:
+ msg2293 |
2007-12-31 23:54:45 | zooko | set | messages:
+ msg2294 |
2008-01-02 18:05:18 | tommy | set | messages:
+ msg2308 |
2008-01-03 22:09:34 | droundy | set | messages:
+ msg2310 |
2008-01-04 21:51:42 | zooko | set | messages:
+ msg2314 |
2008-01-05 15:13:53 | droundy | set | status: unknown -> deferred |
2008-01-07 03:26:22 | markstos | set | status: deferred -> waiting-for nosy:
+ markstos messages:
+ msg2344 |
2008-01-11 20:42:34 | zooko | set | nosy:
markstos, droundy, tommy, darcs-devel, beschmi, kowey, zooko messages:
+ msg2444 |
2008-01-11 20:50:26 | droundy | set | messages:
+ msg2445 |
2008-01-11 23:27:35 | zooko | set | messages:
+ msg2447 |
2008-01-12 05:34:46 | zooko | set | nosy:
+ nejucomo messages:
+ msg2448 |
2008-01-12 15:24:57 | droundy | set | nosy:
markstos, droundy, tommy, darcs-devel, beschmi, kowey, zooko, nejucomo messages:
+ msg2449 |
2008-01-12 16:22:06 | zooko | set | messages:
+ msg2450 |
2008-01-12 21:49:46 | nejucomo | set | messages:
+ msg2452 |
2008-01-12 21:50:49 | tommy | set | messages:
+ msg2453 |
2008-01-12 22:00:10 | tommy | set | messages:
+ msg2454 |
2008-01-12 22:33:16 | tommy | set | messages:
+ msg2455 |
2008-01-13 01:38:46 | zooko | set | messages:
+ msg2458 |
2008-01-13 01:42:06 | zooko | set | messages:
+ msg2459 |
2008-01-14 22:25:21 | droundy | set | messages:
+ msg2495 |
2008-01-14 22:25:35 | droundy | set | messages:
+ msg2496 |
2008-01-14 22:29:42 | daveroundy | set | nosy:
+ daveroundy messages:
+ msg2497 |
2008-01-14 22:29:47 | daveroundy | set | messages:
+ msg2498 |
2008-01-14 23:41:45 | tommy | set | messages:
+ msg2508 |
2008-01-14 23:41:51 | tommy | set | messages:
+ msg2509 |
2008-01-15 09:38:37 | simonmarhaskell | set | nosy:
+ simonmarhaskell messages:
+ msg2514 |
2008-01-15 09:38:46 | simonmarhaskell | set | messages:
+ msg2515 |
2008-02-16 04:07:10 | markstos | set | status: waiting-for -> resolved-in-unstable nosy:
droundy, tommy, beschmi, kowey, markstos, darcs-devel, zooko, nejucomo, simonmarhaskell, daveroundy messages:
+ msg3491 |
2008-09-04 21:31:46 | admin | set | status: resolved-in-unstable -> resolved nosy:
+ dagit |
2008-09-28 20:49:40 | admin | set | nosy:
+ thorkilnaur, simon, - daveroundy |
2009-08-06 17:41:35 | admin | set | nosy:
+ jast, Serware, dmitry.kurochkin, mornfall, - droundy, nejucomo, simonmarhaskell |
2009-08-06 20:38:51 | admin | set | nosy:
- beschmi |
2009-08-10 22:10:10 | admin | set | nosy:
+ simonmarhaskell, nejucomo, - jast, Serware, mornfall |
2009-08-11 00:04:09 | admin | set | nosy:
- dagit |
2009-08-25 17:26:18 | admin | set | nosy:
- simon |
2009-08-27 14:07:53 | admin | set | nosy:
tommy, kowey, markstos, darcs-devel, zooko, nejucomo, simonmarhaskell, thorkilnaur, dmitry.kurochkin |
2009-10-24 00:39:27 | admin | set | nosy:
+ simonmar, - simonmarhaskell |
|