On Wed, Aug 6, 2008 at 11:41 AM, Jason Dagit <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Aug 6, 2008 at 11:29 AM, David Roundy <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Aug 06, 2008 at 11:23:02AM -0700, Jason Dagit wrote:
>> > I think I've tracked the problem down to these hunks:
>> > hunk ./src/Darcs/Repository/Internal.lhs 279
>> > -readPrims s = case readPatch s of
>> > +readPrims s = case readPatch s :: Maybe (Sealed (Prim C(x )),
>> PackedString)
>> > of
>> > hunk ./src/Darcs/Repository/Internal.lhs 281
>> > - Just (Sealed p,_) -> Sealed (effect (p :: Patch C(x y)))
>> > + Just (Sealed p,_) -> Sealed (effect p)
>> >
>> > I have no idea why I was trying to change it from Patch to Prim but that
>> > appears to be a big no-no.
>>
>> It seems reasonable to make this change, but does introduce a bug.
>> When we write and read FL Prim, there's no way to know if the patch
>> sequence was truncated, but if we convert to Patch first, then we have
>> delimiters. This is only marginally useful, but it's the way we do
>> it. It also relates, I should mention, to our need for backwards
>> compatibility with darcs 1 repositories.
>>
>> > I've changed it back locally but now steve_and_monica_rollback.sh runs
>> for a
>> > very long time. This makes me think my patch has huge impact on
>> > strictness. I'm not sure where to begin looking at though. Changing
>> > Repository/Internal.lhs had pretty wide effects in terms of working with
>> > Sealed types and for my experience any of those could be the strictness
>> > culprit.
>>
>> Argh. That's no fun. Do tests pass in general, though?
>
>
> I'm not sure yet. I've discovered by running the commands inside of that
> test manually that when it gets to the last 2 stops a conflict is detected
> and on the last step darcs is trying to get permission (it prompts yorn) and
> that's why the tests hang. Next I'll try running the commands on a known
> good version of darcs so I can compare and then I'll investigate the changes
> in Rollback.lhs.
>
> At least I'm making progress again :)
>
Here is how it looks:
This is the script:
mkdir tmp_steve
mkdir tmp_monica
cd tmp_steve
darcs init --darcs-2
echo A >foo
darcs add foo
darcs record -Asteve -am 'Anote'
echo B >foo
darcs record -Asteve -am 'Bnote'
# Show the history as Steve sees it.
darcs changes -s
echo "######"
cd ../tmp_monica
darcs init --darcs-2
echo A>foo
darcs add foo
echo Z>bar
darcs add bar
darcs record -Amonica -am 'AZnote'
darcs pull -a ../tmp_steve
darcs changes
echo "######"
darcs rollback -a -m newpatch -A me --match 'exact Anote'
# previous failure result: darcs failed: cannot roll back a 'rollback'
patch.
When I run bad darcs it looks like this (only showing the last steps):
$ $DARCS pull -a ../tmp_steve
Backing up ./foo(-darcs-backup0)
We have conflicts in the following files:
./foo
Finished pulling and applying.
$ $DARCS changes
Wed Aug 6 11:33:29 PDT 2008 steve
* Bnote
Wed Aug 6 11:33:08 PDT 2008 steve
* Anote
Wed Aug 6 11:35:06 PDT 2008 monica
* AZnote
$ $DARCS rollback -a -m newpatch -A me --match 'exact Anote'
Backing up ./foo(-darcs-backup1)
We have conflicts in the following files:
./foo
You have conflicting local changes to:
./foo
Proceed? [yn]y
Finished rolling back.
When I run good darcs it looks like this (again only showing the last
steps):
$ darcs pull -a ../tmp_steve/
Finished pulling and applying.
$ darcs changes -s
Wed Aug 6 11:44:23 PDT 2008 steve
* Bnote
M ./foo -1 +1
Wed Aug 6 11:44:11 PDT 2008 steve
* Anote
Wed Aug 6 11:45:12 PDT 2008 monica
* AZnote
A ./bar
A ./foo
$ darcs rollback -a -m newpatch -A me --match 'exact Anote'
No changes selected!
Is the good darcs doing the right thing here? Next up I need to look at why
my darcs is detecting a conflict but previous darcs did not detect a
conflict.
Jason
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
