Re: [Monotone-devel] bug reports?

[graydon hoare]

Tom Tromey <address@hidden> writes:

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

well, don't dispair. I'm sure it *is* fixable, just need to work out
what the nicest form is.

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

thanks. though it's not so much factored as layered; I consciously
permitted duplication or poor factoring where I thought it might
decrease coupling. there are a number of odd coding conventions I've
adopted, but they suit my preferences, and I can provide a rationale
for them. I've found it very easy to hack on.

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

hm. yeah, I somewhat like the idea up until it involves patch_set. I
don't think it needs to use patch_set. the function
calculate_new_manifest_map in commands.cc will see all the relevant
missing files, it can trap those and just dump them into a second
return parameter, a set of paths, and the command can do what's
appropriate.

a patch_set is already a pretty complex data object -- the worst in
the program, I think -- and handling a "monotone rename foo bar"
command is already going to make it a little more complex, giving it
an explicit map connecting names which don't have the same SHA1. I
really don't want to add much else to it unless necessary.

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

yeah, so then status will just say "so and so is missing", update will
rewrite the missing file to its state in the target manifest in its
entirety even if there was no delta, and as you say, commit will
fail. let's do that.

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

the arguments are a list of cert names to sort on. for a fanciful
future example:

 $ monotone update builds approved quality ancestry date 

will sort the set of update candidates first by whether they build,
then by whether they're approved, then by their quality metric, then
by their ancestry, and finally (if there's more than one head in that
set) by their date. then it'll update to the version which won all
those sorts. the sorting is done by successive elimination. so you
might not update to the very head of your version graph if you don't
have any evidence that it builds yet, for example. 

I welcome a UI change here, but the functionality needs to be
preserved somehow. it can be in a lua hook or something. obviously the
plain ancestry-based update needs to work first, and easily, because
it's what people expect. but I don't want to bury the more advanced
forms of update too deep. also, as you say, some sort of "update just
one file" feature might be nice. also "show updates". lots of UI to
add here.

-graydon