Dan Pascu <dan <at> ag-projects.com> writes: > > On Tuesday 16 December 2008, florent.becker <at> laposte.net wrote: > > 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. > > This is the road to management nightmare. No matter what hooks you use, > whenever there is duplicate data, it will become desynchronized sooner or > later and you need to constantly make sure they are in sync. If such a > solution would be chosen to deal with the problem I wouldn't even > consider using it. > There has to be duplication of data in order to get backwards compatibility, since pull does not call a remote darcs. Whether this duplication of data is done by darcs itself or by a hypothetical darcs-mirror does not matter that much, does it?
On the other hand, we need the user to choose between packed, unpacked and both. Using both by default is a bad idea, since it means doubling the size of every repository in existence. > IMO, these things should be transparent for the end user, not require him > to setup and maintain parallel repositories. Otherwise people will move > to a simpler solution, one that interferes less with their work and just > works. That's a valid point. All in all, the simplest thing to do is to have two inventories and patch directories. Whether this is done by some more code in darcs' core or in a more external layer does not matter. I think writing a darcs-mirror executable that keeps two repositories in sync is a useful thing in general (to circumvent firewalls, for repositories on usb keys, and so on), and that it allows us to solve the problem at hand. Of course, darcs init --packed --unpacked-mirror=DIRECTORY should be all the user needs to do, all the rest is magical. This also allows us to eventually phase out unpacked repositories, should we ever want to. My current plan anyway is first implement packs in a non-backwards-compatible way to see how well they fare (this should stay in the branch), then make them backwards-compatible (however we choose to do that) and merge that into the mainline. > > Any solution based on data duplication is a bad idea IMO, unless the > purpose is to have redundant data to recover from a disaster. > In the presence of dumbservers, data duplication is indispensable in order to get backwards compatibility. We can only make it easier on the user. Florent _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
