[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] bug reports?
From: |
Tom Tromey |
Subject: |
Re: [Monotone-devel] bug reports? |
Date: |
07 Sep 2003 13:48:17 -0600 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
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