[darcs-devel] Re: [darcs #251] Rollback over dependencies.

[David Roundy]

(splitting my reply into bug-related and unrelated bits, to avoid clutter
in the BTS...)

On Tue, Mar 08, 2005 at 11:57:34PM +0000, Tuomo Valkonen wrote:
> For other reasons, I've been thinking that it might be better to record
> patches in a "minimal context" (smallest set of depended-upon patches; every
> tag being minimal) and each patch would store this context, instead of using
> separate patch bundles. This would enable support for signed patches and
> "freely floating patches". I read in an old thread that computing this
> minimal context when moving patches between repositories would be too
> inefficient. But would it be too inefficient already at record time?
> Intuitively it doesn't seem so (we're just commuting a few hunks instead of
> a great part of a repository as far back as possible), but I don't know the
> darcs internals too well. For other performance reasons, I'd been thinking
> that patches could also include an unsigned version of themselves for
> "current/repository context", but this would obviously not work with
> multiple rollbacks (and each rolled back patch would have to be stored
> separately, thus requiring rollback counters, changing the date of the or
> something like that, to keep track of the differing multiple rollbacks),
> while just storing the minimal context would.

Storing minimal-context patches would *definitely* be too expensive.  Darcs
get, for example, would then be O(N^2) rather than O(N), and the current
O(N) get already takes something close to a day on my computer to get the
linux kernel repository.  I don't like the idea of multiplying that by
26,000...

> As for handling conflicts in a scheme where patches are stored only in
> their minimal context, I think that files in _darcs/current should 
> regardless of this be  stored in an augmented format that includes 
> conflict markers, symlink information, exec bit information, and so on. 
> Currently in case of conflict _darcs/current does not "match" the result
> of the chain of patches in the repository, and I think this is wrong.
> _darcs/current should store all the "heads" of the repository.

Definitely we need to keep track of conflicts, but contrary to your
assertion, in case of conflict, _darcs/current *does* match the result of
the chain of patches.  Conflict markers/resolutions should kept track of in
something akin to "pending".

By "store all the 'heads' of the repository", do you mean that we should
reconstruct the graph of versions when there is a conflict, and then store
all conflicting versions separately?

As for storing things like the executable bit and symlinks, we don't need
to modify the format of _darcs/current/ to do that, we just need to add a
new patch type that versions such objects.
-- 
David Roundy
http://www.darcs.net