On Wed, 17 Jun 2009, Ingo Oeser wrote: > Hi Daniel, > > On Tuesday 16 June 2009, Daniel Barkalow wrote: > > You should be able to have the slave repositories store tags for tree > > objects (instead of commit objects), and have the webservers fetch those. > > You'll still have the object database, but it will only contain stuff > > that's been deployed to that webserver, not intermediate versions or > > historical versions. > > Ah, that sound like a great solution. I'll try that. > > > You'll still have to store both the repo and the checked out data > > (but git stores the content delta-compressed against each > > other in one big file, normally, so there really aren't files to hard link > > to. > > Ok. That was under the assumption, that the core of git is basically a > content addressable file system. But that seems to be history :-) It is (based on) a content-addressable file system, but it's not a host file system. It's a file system in the sense that you can put octet sequences into it and lookup them up by their names, but you can't mount it from the kernel and link to it. It's like a tar file, although it's more limited in that it doesn't provide a "list" operation. There's no fundamental reason there couldn't be a kernel driver (or, more likely, FUSE helper) which could mount it, but that's not the normal method. > > Of course, the other possibility is to check out versions on the slaves, > > and rsync that to the webservers, which is probably the optimal method if > > you're not in a situation where you benefit from anything git does in > > transit. > > I would benefit from noticing local changes. But simple rsync is what is tried now. > Problem is, we get no de-duplication from rsync, which git could do. In that case, fetching trees is probably the right thing; that should give you a point-to-point de-duplication without any history (although you may also turn up git bugs, since this isn't how git is normally used). -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html