Gwern Branwen wrote: > Format negotiation sounds scary and complex to implement. There's no > dumb solution here? For example, I was thinking: what if there were > _darcs/packs/, which contained the pack files, and then pack-enabled > darcs binaries would automatically look for a _darcs/packs/ when doing > a get; older darcs have no reason to look for a packs/ subdirectory > and so would just ignore it.
I agree... Packs are an ancillary data source that don't necessarily need to conflict with existing repository data and it seems to me that they can be placed side-by-side without impacting backward compatibility and without requiring a new repository format. Additional to Gwern's suggestion: perhaps a _darcs/inventories.packed/ directory that mirrors the existing (hashed) _darcs/inventories/ directory. When darcs with pack support goes to grab an archived (tagged) inventory it could check for the inventory hash in _darcs/inventories.packed/ first, then fallback to _darcs/inventories. It seems that the existing splitting of archive inventories roughly mirrors what the pack format seems to do, so mirroring that at the repository makes a lot of sense to me. The pack could even _be_ the compressed inventory file at inventories.packed with each patch fully described/expanded inline in the inventory rather than being just a hash pointer... Plus I would assume that packed inventories could sit on top of the existing darcs optimize support that splits and manages archive inventories... Also, Camp's pack-like format may be a useful counter-study here. -- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
