Re: [Monotone-devel] unhexification of revision hashes

[Zack Weinberg]

On Jan 28, 2008 12:36 PM, Markus Schiltknecht <address@hidden> wrote:
> I've just committed a revision 47dc584d4ca8799f686b20ce9bf5c59eb69f6d3c
> into branch n.v.m.experiment.db-compaction. Todays fixes made it pass
> all unit and lua tests, and together with the addition to NEWS, I now
> consider that revisions to be ready for landing on mainline. Please review.

Ok, I've read this code over.  I like it, but unfortunately, there are
some blocker issues.

1) There are a lot of places where you changed strings to hexenc<id>s.
 This makes the substantial changes very hard to find.  I'd actually
like you to have gone further, if possible, and used the DECORATE
types wherever possible (revision_id etc) -- but I think you should
make those changes on mainline as a separate patch.

Because of this, I can't promise that I didn't miss some other glaring
problem that will require a third go-round once we can see the smaller
diff.

2) On .experiment.encapsulation, selector completion is done totally
differently.  I'm not sure what prefix_matching_constraint() needs to
turn into, but I'm sure it won't work in its present form after .e.e
lands.

I would like to call the pumpkin for landing .experiment.encapsulation
before this or any other branch; I need only another couple days on
it, and it's well past the point where large merges from mainline are
tractable.  Sorry.  This also means, please *don't* do the string ->
foo_id changes until after .e.e lands.

3) Zbigniew's performance issues need to be investigated before merging.

zw