Re: [Monotone-devel] bug reports?

[Tom Tromey]

graydon> I think the savannah one will be my default choice unless you
graydon> feel like setting up some other BTS.

Ok, let's use the savannah one.

>> rm commands.cc
>> monotone update

graydon> it's a bit hard to fix though

Tell me about it :-).  I looked at it a bit yesterday but in the end
gave up.

graydon> if I took it *out* of your in-memory manifest, then it would
graydon> be merged with its update target as a representation of a
graydon> "delete"

That's the approach I tried, and indeed I got exactly what you
predict.  BTW, the monotone code is quite nice.  It's a little hard on
me, since my C++ knowledge pre-dates the STL :-).  But I like how
well-factored everything seems.


Another idea I had was to change patch_set to have a separate list of
"missing" files.  Then each command using patch_set would be updated
to handle this situation.

E.g., commit could simply fail, update could re-fetch, and status
would print "missing".

This seemed a bit unclean.

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

That doesn't fix the "monotone status" case, which I didn't mention in
my report, but which also prints an error in this situation.


graydon> monotone cat file `awk '/commands.cc/ {print $2}' MT/manifest` 
graydon> commands.cc
graydon> would, I think, do what I have in mind for "revert". it's kinda better
graydon> than "update" since it would avoid merging in any changes you're not
graydon> yet ready to receive.

I didn't see any documentation on the arguments to "monotone update".
What do these do?  I'm wondering if "monotone update <manifest-hash>"
will work to avoid merging in new changes.

Tom