[darcs-devel] [issue710] boringfile pref bug

Adrian Irving-Beer bugs at darcs.net
Wed Feb 27 14:43:08 UTC 2008


New submission from Adrian Irving-Beer <wisq at wisq.net>:

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

	bar

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

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

	bar

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:

	thisrepo:/tmp/bar
	repo:alpha:/tmp/bar
	repo:/tmp/foo
	)

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. :)

----------
messages: 3678
nosy: beschmi, droundy, kowey, tommy, wisq
status: unread
title: boringfile pref bug

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue710>
__________________________________


More information about the darcs-devel mailing list