> Message du 16/12/08 09:26 > De : "Stephen J. Turnbull" <[email protected]> > A : [email protected] > Copie à : "'Gwern Branwen'" <[email protected]>, "'Darcs Mailing list'" > <[email protected]>, "'Florent Becker'" <[email protected]> > Objet : RE: [darcs-users] http://code.haskell.org/darcs/packs is back > > > Max Battcher writes: > > 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. > > I suppose this works for pulling, with a dumb server such as an httpd. > > But it fails badly with a push; you end up stuffing packs down the > throat of a server process that can't handle them. > I think format negociation is a good thing to have. Juliusz proposed the following scheme: client sends an option command followed by a list of format it understands server replies with its favorite format among these. Of course, this in itself can only be done in a backward-incompatible way. But once we have it, it makes backwards compatibility easier to achieve. Note two things, as far as packs are concerned: -backwards incompatibility only matters for pulling/getting from a "public" repository, push/send remains compatible between packed and unpacked repositories -Contrarily to darcs 1 vs darcs 2, there's no semantic difference, which means that convert is innocuous. For these two reasons, i think the easiest way is to stop worrying about backwards compatibility and have an unpacked mirror for each public packed repository, with post-hooks on each that ensure they keep in sync. Otherwise, as for packs, i'm not exactly sure how to achieve backwards compatibility, or even if is desirable. I think we need to have either several inventories in each repo, or repositories with several alternative for fethching each patch. In each case, this means having each operation being done in parallel on all the formats, which is not appealing. Maybe we should just have packs be in a separate directory (_darcs/packs) with a file (pack-contents) that maps each patch id to a pack. Then (get/pull) would just download that file, deduce a list of packs it needs, and get them. Both of these solutions seem too complicated to me, so i'd say we should go the simple route. Anyway, maybe trying out packs will show they're not worth it, and problem solved. Florent Créez votre adresse électronique [email protected] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. Créez votre adresse électronique [email protected] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
