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

On Wed, Feb 27, 2008 at 02:43:09PM -0000, Adrian Irving-Beer wrote:
> Hi, found three bugs and thought I'd report them.

We appreciate the bug report, but would have appreciated it even more if
you had sent three separate bug reports, as that makes it easier for us to
deal with the issues separately.

> Bug #1:  "darcs whatsnew --look-for-adds" implies --summary.

This is a feature, not a bug.

> Bug #2:  Add a file, set as boringfile, "record --look-for-adds",
> 	 bogus remove in next whatsnew.

This sounds like an annoying sort of bug that has plagued us before, but
I'm surprised that the setpref boring is associated with it.

> Bug #3:  Repo A host X ==get==> repo B host X ==get==> repo C host Y,
> 	 repo C cannot see repo A's patches.

I'll reply to this separately (and maybe move it off into a separate bug
report).

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

Would you by any chance be willing to write this sequence (for #2) up as a
script? That would enable me to pretty easily add it to our test suite
(which is the best way to start fixing it).

David

On Wed, Feb 27, 2008 at 02:43:09PM -0000, Adrian Irving-Beer wrote:
> Bug #3:  Repo A host X ==get==> repo B host X ==get==> repo C host Y,
> 	 repo C cannot see repo A's patches.

darcs get --lazy is no longer the default, so the issue can only happen if
a user explicitly asks for a lazy repository, in which case that user gets
what he or she asked for.

We make an attempt to alleviate this issue by adding to our sources list
the sources of the repository we're getting, but that's only effective if
we actually have access to those repositories, and I don't think it's
productive to try to figure out how to access remote repositories via local
URLs.  (Although we could do this.)

The long and the sort of it is that I'm considering #3 resolved.  If you
disagree, please open a new wishlist bug describing the behavior you'd
like.
-- 
David Roundy
Department of Physics
Oregon State University

On Mon, Mar 03, 2008 at 04:35:42PM -0000, David Roundy wrote:

> We appreciate the bug report, but would have appreciated it even more if
> you had sent three separate bug reports, as that makes it easier for us to
> deal with the issues separately.

Yeah, my apologies -- as the subject implies, I only originally meant
to report #2, but while writing up the report, I came across #1.  Then
I remembered #3 as well.  Not being sure whether 'bugs@darcs.net' went
to a human or directly to the bug tracker, I was left to guess whether
fewer or more e-mails were preferred, and I picked fewer for
simplicity's sake.

> > Bug #1:  "darcs whatsnew --look-for-adds" implies --summary.
> 
> This is a feature, not a bug.

Hm, okay.  I guess it's just a surprising feature, then.

I use look-for-adds in my ~/.darcs/defaults, and on the rare occasion
I tried using dont-look-for-adds for a project, it took me some time
to realise why the output was so different (and how to fix it).

> > Bug #2:  Add a file, set as boringfile, "record --look-for-adds",
> > 	 bogus remove in next whatsnew.
> 
> This sounds like an annoying sort of bug that has plagued us before, but
> I'm surprised that the setpref boring is associated with it.

Well, the setpref boring seems to be a sure-fire way to evoke it, but
I've just today had a directory and its contents appear in the same
"removed yet auto-added" state, so it's certainly not the only way.

(The directory was added via --look-for-adds, with said directory
specified on the command line for record.)

> > Bug #3:  Repo A host X ==get==> repo B host X ==get==> repo C host Y,
> > 	 repo C cannot see repo A's patches.

Per your response, I'd tend to agree that this can be closed -- had I
initially understood lazy fetching and had explicitly chosen it, I
would have been much less confused and could repair the source repos
accordingly.

> Would you by any chance be willing to write this sequence (for #2) up as a
> script? That would enable me to pretty easily add it to our test suite
> (which is the best way to start fixing it).

Sure, I'll send one along when I get a chance (soon).

Hi Adrian,

We'd love to have a test for your bug #2, if you can spare a few moments.  The
best would be to submit it as a patch to our bugs/ directory, but whatever you
can put together would be great.  Thanks!

Nicolas has submitted a test case for this.  Thanks!

The test is bugs/pending-look-for-adds.sh

And I would like to add that this bug is not directly related to setpref but
more to having a certain thing in pending and using look-for-adds.

Moreover this is a regression from darcs1.

I'm not competent on this part of the code :(

The following patch updated the status of issue709 to be resolved:

* resolve issue709: avoid adding changes to pending in rmpend when possible.