On Thu, May 28, 2009 at 08:58:23AM -0400, C. Michael Pilato wrote:
> When I rewrote the commit driving code a long time ago, I anticipated the
> need to handle commits to multiple repositories. The code may have gone a
> bit stale, but the logic that harvests "committables" stores those items in
> a hash that was designed to be primarily keyed on some unique repository
> attribute (UUID, repos URL, or something). Of course, I think this was back
> before we stored such things in our working copy, so I used a single static
> key for that hash for the time being. But I still hold some hope that that
> code can be revived and massaged into doing what is expected.
So you're saying that there already are provisions in the existing
code for the "commit to multiple repositories" problem which are
orthogonal to what Hui Huang is doing?
I mean, according to your description, the current data structure
hierarchy looks somewhat like this:
+-----------------+
| repo hash table | <-- keyed statically right now,
+-----------------+ so it only has one entry
|
v
(commitables) <-- list of commitables (or a hash table or whatever)
When we start storing commitables for multiple working copies,
we will still have commitables grouped per repository anyway.
So we'll change the above to something like:
+-----------------+
| repo hash table | <-- still keyed statically
+-----------------+
|
v
(commitables WC1, commitables WC2, ..., commitables WCn)
Extending the commit mechanism to use multiple keys into the
per-repository hash instead of a static one is something which
can still be done later. It even could be done right now before
Hui Huang works on the code, because it's "one level above"
of what he is doing.
Did I understand you correctly?
Stefan
Received on 2009-05-28 15:25:53 CEST