darcs

Message3838

Author wisq
Recipients beschmi, droundy, kowey, tommy, wisq
Date 2008-03-07.20:31:07
Issue Issue709 setpref boringfile foo => darcs thinks foo is removed
Content
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).
History
Date User Action Args
2008-03-07 20:31:07wisqcreate
2008-03-07 20:31:09wisqlinkissue709 messages
2008-03-07 20:31:09wisqsetrecipients: + wisq, wisq
2008-09-20 14:42:42adminsetrecipients: - wisq
2008-10-09 20:35:55adminunlinkissue709 messages
2008-10-09 20:36:08adminlinkissue709 messages