Issue 710 boringfile pref bug

Title boringfile pref bug
Priority bug Status duplicate
Milestone Resolved in
Superseder setpref boringfile foo => darcs thinks foo is removed
View: 709
Nosy List darcs-devel, dmitry.kurochkin, kowey, thorkilnaur, tommy, wisq
Assigned To

Created on 2008-02-27.14:43:08 by wisq, last changed 2009-08-27.13:56:06 by admin.

msg3678 (view) Author: wisq Date: 2008-02-27.14:43:06
Hi, found three bugs and thought I'd report them.

Bug #1:  "darcs whatsnew --look-for-adds" implies --summary.
Bug #2:  Add a file, set as boringfile, "record --look-for-adds",
	 bogus remove in next whatsnew.
Bug #3:  Repo A host X ==get==> repo B host X ==get==> repo C host Y,
	 repo C cannot see repo A's patches.

Here's #1 and #2, with commands spaced for readability:

	% darcs --version
	2.0.0pre3 (unknown)

	% darcs init

	% echo -n 'testing' > _darcs/prefs/author

	% echo 'test file 1' > foo

	% darcs whatsnew --look-for-adds
	a ./foo

	% darcs record --look-for-adds --all -m"Patch 1"
	Finished recording patch 'Patch 1'

	% darcs whatsnew --look-for-adds
	No changes!

	% echo 'test boringfile' > bar

	% darcs setpref boringfile bar
	Changing value of boringfile from '' to 'bar'

	% darcs whatsnew
	changepref boringfile


	% darcs whatsnew --look-for-adds
	a ./bar

	% darcs whatsnew --look-for-adds --no-summary
	addfile ./bar
	hunk ./bar 1
	+test boringfile
	changepref boringfile


This demonstrates bug(?) #1:
The --look-for-adds option automatically implies --summary.

	% darcs record --look-for-adds --all -m"Patch 2"
	Finished recording patch 'Patch 2'

	% darcs whatsnew --look-for-adds
	R ./bar
	a ./bar

This demonstrates bug #2:
Adding a boringfile via --look-for-adds seems to do weird stuff.

	% echo 'test file 3' > baz

	% darcs record --look-for-adds --all -m"Patch 3" 
	Finished recording patch 'Patch 3'

	% darcs whatsnew --look-for-adds
	R ./bar
	R ./baz
	a ./bar
	a ./baz

Bug #2 persists on files added after the boringfile.
This is probably the most disturbing aspect.

	% darcs add bar

	% darcs whatsnew --look-for-adds
	R ./baz
	a ./baz

	% darcs add baz

	% darcs whatsnew --look-for-adds
	No changes!

	    [Bug #2's leftovers have been cleaned up;
	     now we see if the effect continues.]

	% echo 'test file 4' > qux

	% darcs record --look-for-adds --all -m"Patch 4"
	Finished recording patch 'Patch 4'

	% darcs whatsnew --look-for-adds
	No changes!

Once you manually clean up the debris from bug #2, it doesn't reoccur.

To reproduce bug #2, it seems to require that you create a file in the
same patch as you assign it as the boringfile, and that you record it
via --look-for-adds.  If you do them in separate patches, or if you
"darcs add" the file, the bug goes away.

There's also bug #3, which is related to the lazy patch fetching.
Here's the command flow, with the path and host in the prompt:

[on host 'alpha']

	alpha:/tmp/foo% darcs init --darcs-2

	alpha:/tmp/foo% echo -n 'testing' > _darcs/prefs/author

	alpha:/tmp/foo% echo 'test file 1' > foo

	alpha:/tmp/foo% darcs record --look-for-adds --all -m"Patch 1"
	Finished recording patch 'Patch 1'

	alpha:/tmp/foo% cd ..

	alpha:/tmp% darcs get foo bar
	Finished getting.

[on host 'beta']

	beta:/tmp% darcs get alpha:/tmp/bar bar
	Finished getting.

	beta:/tmp% cd bar

	beta:/tmp/bar% darcs check
	darcs: failed to read patch:
	Tue Feb 26 16:42:26 EST 2008  testing
	  * Patch 1
	user error (Couldn't fetch d5fa8f5bb76f8f22f0145dc22acae853a59ca6e'
	in subdir patches from sources:


The problem here is that although beta:/tmp/bar inherited
alpha:/tmp/bar's sources, it didn't rewrite the host.  Hence, lacking
a (local) repo at beta:/tmp/foo, it can't get the patches.

The tricky thing here is that everything seems fine, at least
until you try to do a 'check', 'annotate', 'unpull', etc.

Worse yet, the first command you're likely to run is 'check' (assuming
it isn't 'check' that broke), and to the average user, it then looks
like the repository is corrupt in an irreparable way.

The temporary fix:

[on host 'alpha']

	alpha:/tmp/bar% darcs check
	The repository is consistent!

[on host 'beta']

	beta:/tmp/bar% darcs check
	The repository is consistent!

Running 'darcs check' on the intermediary (alpha:/tmp/bar) repo fixes
this, because it loads all the patches where the final (beta:/tmp/bar)
repo can find them.

Otherwise, I've had no troubles with the darcs 2 prereleases so far.
Good to see a great tool get even better.  Darcs has the best UI and
best patch mechanic (unordered "bag of patches") of any SCM out there.
I've even got my somewhat SCM-averse co-worker to use it, and without
any trouble whatsoever. :)
Date User Action Args
2008-02-27 14:43:08wisqcreate
2008-02-29 14:49:02droundysetpriority: bug
status: unread -> duplicate
superseder: + setpref boringfile foo => darcs thinks foo is removed
nosy: + wisq, - wisq
2009-08-06 17:55:06adminsetnosy: + markstos, jast, Serware, dmitry.kurochkin, darcs-devel, zooko, dagit, mornfall, simon, thorkilnaur, - droundy, wisq
2009-08-06 20:59:02adminsetnosy: - beschmi
2009-08-10 22:16:20adminsetnosy: + wisq, - markstos, darcs-devel, zooko, jast, dagit, Serware, mornfall
2009-08-25 18:06:20adminsetnosy: + darcs-devel, - simon
2009-08-27 13:56:06adminsetnosy: tommy, kowey, darcs-devel, thorkilnaur, wisq, dmitry.kurochkin