Re: Local clones aka forks disk size optimization

The problem here, IMHO, is the assumption, that the main repo will never be cleaned up. But what to do if you dont wanna let it grow forever ?

hmm, distributed GC is a tricky problem.

maybe it could be easier having two kind of alternates:

a) classical: gc+friends will drop local objects that are 
   already there
b) fallback: normal operations fetch objects if not accessible
   from anywhere else, but gc+friends do not skip objects from there.

And extend prune machinery to put some backup of the dropped objects to some separate store.

This way we could use some kind of rotating archive:

* GC'ed objects will be stored in the backup repo for some while
* there are multiple active (rotating) backups kept for some time,
  each cycle, only the oldest one is dropped (and maybe objects
  in a newer backup are removed from the older ones)
* downstream repos must be synced often enough, so removed objects
  are fetched back from the backups early enough

You could see this as some heap:

* the currently active objects (directly referenced) are always
  on the top
* once they're not referenced, they sink a lever deeper
* when the're referenced again, they immediately jump up to the top
* at some point in time unreferenced objects sink too deep that
  they're dropped completely

cu