Re: [Monotone-devel] bug reports?

[graydon hoare]

Tom Tromey <address@hidden> writes:

> Graydon, how would you like bug reports?
> 
> I can send email or I could upload them into savannah.  Personally, I
> don't like the savannah bug tracking system...

that's a good question. I don't really *like* the savannah tracker
either, on the other hand it's already there, and I think it's less
likely to lose a bug than just keeping bugs in email folders. I think
the savannah one will be my default choice unless you feel like
setting up some other BTS.

really I've never used a bug tracking system I much liked. they always
feel a bit un-integrated into the tools at hand, like you spend too
much time getting information out of them and putting it back in. in
the back of my mind it's been a thought to integrate bug tracking into
monotone too (and produce a tighter bug -> testcase -> cert workflow)
but that's pretty blue-sky at this point. it doesn't even understand
how to read test results yet.

> Here's the first one.  I did:
> 
> rm commands.cc
> monotone update
> 
> I expected this to work the way it does with cvs -- re-fetch the
> missing file.  Instead I get the appended.

hm. well, yeah, that's a bug I guess. it represents one of the only
cases I can think of where the state of the {base manifest + worklist
+ changes-to-SHA1s} *doesn't* represent a subset of the working copy.

it's a bit hard to fix though: it's trying to build an in-memory
manifest of "what you mean to have in your working copy", so that it
can merge that with a selected update target and write the patchset
which represents a delta from current to merged.

if I assume that you mean to have commands.cc in your working copy,
then I'd leave it in your in-memory manifest (current) even though
it's not in your working copy, but then there would be no writing out
of the file since it didn't change between current and merged.

if I took it *out* of your in-memory manifest, then it would be merged 
with its update target as a representation of a "delete", which would
probably win the merge assuming nothing else happened to commands.cc
during the update. that would be worse.

so perhaps the thing to do is adopt the first strategy -- assume you
want that file still -- but keep a secondary list of failed opens
during the first phase, and then once we've selected a merge target
and written everything else in the patchset, rewrite the files named
in those failed opens (minus any written by the patchset), as they
appear in merged. it's sort of a special case, since the deletion was
essentially an accident, or at least doesn't represent any intention
to change things on your part.  it's a roundabout (although common)
way of requesting a "revert" operation on a single file.

hm. we could also just add a "revert" command, which can take a
filename. that's super easy. would that be good enough?

> Doing "monotone checkout" worked, but I suspect that would overwrite
> any other changes I have in the tree...

yes, it would. however, doing:

monotone cat file `awk '/commands.cc/ {print $2}' MT/manifest` 
  >commands.cc

would, I think, do what I have in mind for "revert". it's kinda better
than "update" since it would avoid merging in any changes you're not
yet ready to receive.

-graydon