From: Daniel Barkalow Date: Mon, 06 Jun 2005 16:21:19 GMT Subject: Re: Database consistency after a successful pull Message-ID: In-Reply-To: <1118065849.8970.37.camel@jmcmullan.timesys> On Mon, 6 Jun 2005, McMullan, Jason wrote: > Subject Was: [PATCH] pull: gracefu[PAlly recover from delta retrieval > failure.] > > [snip lots of really good information about the thinking > behind the design of the pull mechanisms ] > > Ok, so would I be correct in the following assumptions > about the validity of a 'consistent' .git/objects database: > > ============================================================ > > Commits: > * May have the tree they refer to in the database > * Must have their parents in the database May have their parents in the database; we want to be able to drop ancient history from non-archival sites at some point, if nothing else. > Trees: > * Must have the blobs they refer to in the database > * Must have the trees they refer to in the database It's probably true that there's no point to having a tree available if you don't have its contents, although that's a convenient intermediate stage, so that you can look up the contents of the tree with the ordinary parsing code. On the other hand, I could imagine an ARM developer completely ignoring arch/i386 (and just having write-tree use the parent tree's value for it). > Deltas: > * Must have the referred to object in the database Yes. Can't unpack without them. > Blobs: > * No references to check Right. Also, tags reference objects of unknown type; it's probably not vital to have the object. My bias is to call a database consistent with only deltas having the referents; the rest goes towards completeness, since you have and can read everything that you have anything for (but may not be able to do some particular operation). -Daniel *This .sig left intentionally blank*