<Repeat of email to darcs-users>

Hi

One of my clients stumbled across a very specific set of operations  
that cause data loss.  Fortunately it was really minor (a few lines),  
but very suprising behaviour.  It happens when pulling a patch that  
renames a file AND replaces a token with the token chars '[%r/]'.   
Darcs says there is a conflict, but does not create a backup file with  
the existing data.

Is this is a bug, or are we abusing `darcs replace`?  (Or both?)

Replication steps below.

Thanks
Ashley

% mkdir repo1
% cd repo1
% darcs init

% cat >testfile <<END
Given %r/I have a file/ do
end
END
% darcs record -alm "Add testfile"

% cd ..
% darcs get repo1 repo2

% cat >>testfile <<END
Given %r/something else/ do
end
END

% cd ../repo1
% darcs mv testfile testdata
% darcs replace --force --token-chars '[%r/]' '%r/' '/' testdata
% darcs record -am "Rename testfile and replace a symbol"

% cd ../repo2

% cat testfile
Given %r/I have a file/ do
end
Given %r/something else/ do
end

% darcs pull -a
Pulling from "/Users/ashleymoran/Documents/Development/work/darcs/ 
repo1"...
We have conflicts in the following files:
./testdata
Finished pulling and applying.

% cat testdata
Given /I have a file/ do
end

% ls
_darcs		testdata

Note that Ashley is specifically referring to the fact that darcs fails to
notice that it should back up the working directory file.

And note also what looks like the beginnings of a regression test case!

In the email thread where we left off,  
http://lists.osuosl.org/pipermail/darcs-users/2009-March/018549.html

I think the next action was for Ashley to submit a test case (in the form of a
bugs/ shell script)

This is still in my GTD app, it will just take me a while to get round  
to.  I've got an absolute stack of work lined up now...

I am happy to do this, but if anyone wants to take it up (which,  
according to Eric, would be trivial for anyone used to darcs's test  
harnesses), that would get the issue resolved much quicker.

On 9 Apr 2009, at 12:49, Eric Kow wrote:

>
> Eric Kow <kowey@darcs.net> added the comment:
>
> In the email thread where we left off,
> http://lists.osuosl.org/pipermail/darcs-users/2009-March/018549.html
>
> I think the next action was for Ashley to submit a test case (in the  
> form of a
> bugs/ shell script)
>
> ----------
> assignedto:  -> ashley.moran
> nosy:  -darcs-users
> priority:  -> bug
> status: chatting -> need-info
> title: Data loss bug when renaming and replacing a non standard  
> token? -> unrecorded changes lost when renaming and replacing a non  
> standard token?
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue1400>
> __________________________________

Hi Ashley,

If you could update your GTD app: I've tried to reproduce your error with this
test script, but it seems to be backing up the file as intended.  Can you read
over it to verify that this is the same test?  If so, could you try running it
on your end and let me know what happens?  Note that I'm using Darcs 2.3, so
maybe this is a difference between Darcs 2.2 and 2.3, but I don't see what would
have changed.

For convenience, it's also attached as a darcs test that you can run with cabal
test tests/failing-issue1400_replace_backup.sh


rm -rf R S                      # Another script may have left a mess.
darcs init      --repo R        # Create our test repos.
cat >R/testfile <<END
Given %r/I have a file/ do
end
END
darcs record    --repo R -lam 'Add f.'

darcs get R S
darcs mv        --repo R testfile testdata
darcs replace   --repo R --force --token-chars '[%r/]' '%r/' '/' testdata
darcs record    --repo R -am "Replace a symbol"
cat >>S/testfile <<END
Given %r/something else/ do
end
END
darcs record    --repo S -am "Add a line"

darcs pull      --repo R S -a

Attachments

• failing-issue1400_replace_backup.sh

Hi Eric

I don't think the script you attached was exactly what I originally  
did - but then, I noticed a mistake in mine that makes it ambiguous.   
I've attached a revised script.  When I run it, I get neither:

   Given %r/something else/ do
   end

nor

   Given /something else/ do
   end

in S.  It is not in testdata, and there is no backup file.  Do you  
observe the same behaviour?

Note: I'm using darcs 2.2 still, as last time I checked, the MacPorts  
maintainer for darcs had not updated the portfile.  I'll check again  
when I have a stable internet connection.

Ashley

Attachments

• failing-issue1400_replace_backup.sh
• unnamed

Hi Ashley,

On Wed, Aug 26, 2009 at 10:28:18 +0000, Ashley Moran wrote:
> I don't think the script you attached was exactly what I originally  
> did - but then, I noticed a mistake in mine that makes it ambiguous.   
> I've attached a revised script.  When I run it, I get neither:

We're getting closer.  I've simplified away the move, and the weird
tokens, leaving behind only two elements: --force and an unrecorded
file and I also get neither backup file nor conflict marker.

Does the attached file still match your test?

Attachments

• failing-issue1400_replace_backup.sh

On 26 Aug 2009, at 12:13, Eric Kow wrote:

> We're getting closer.  I've simplified away the move, and the weird
> tokens, leaving behind only two elements: --force and an unrecorded
> file and I also get neither backup file nor conflict marker.
>
> Does the attached file still match your test?

When I run your latest test (in darcs 2.2), I get a backup file  
containing the missing data.  BUT, when I put the move back in, I get  
data loss.  So it appears to be just move+replace causing it, and the  
token string was a red herring.

Do you see the same behaviour as me?

Ashley

Attachments

• failing-issue1400_replace_backup.sh
• unnamed

On Wed, Aug 26, 2009 at 11:54:21 +0000, Ashley Moran wrote:
> When I run your latest test (in darcs 2.2), I get a backup file  
> containing the missing data.  BUT, when I put the move back in, I get  
> data loss.  So it appears to be just move+replace causing it, and the  
> token string was a red herring.
> 
> Do you see the same behaviour as me?

Nope. I get the data loss with or without the move.  I agree that
--token-spec is a red herring, but it sounds like you need --force here
(although if you could simplify that to just plain old replace, great!)