Re: Local clones aka forks disk size optimization

[Enrico Weigelt <enrico.weigelt@vnc.biz>]

> Provide one "main" clone which is bare, pulls automatically, and is
> there to stay (no pruning), so that all others can use that as a
> reliable alternates source.

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
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de