Re: design document

Stefan Sperling wrote:
> 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?

I wasn't anticipating the change you seem to be proposing, where the
committables are grouped by working copy.

My redesign of the commit process long ago assumes no need to group
committables by working copy, only by repository. Commits are driven based
on the committable's URL today -- *not* based on its working copy path.
That's what allows us to theoretically get atomicity in a commit that spans
multiple working copies which point to the same repository.

Again, the code may be so stale and so tweaked by now that the design I had
in mind is now useless. And I'm certainly not tied to those old ideas. I
just don't want to see unnecessary effort invested if we can avoid it.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2356178