[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] unhexification of revision hashes
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] unhexification of revision hashes |
Date: |
Mon, 28 Jan 2008 16:48:29 -0500 |
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