[darcs-users] Re: darcs - the CVS replacement for our company?
droundy at abridgegame.org
Sat Mar 5 15:58:18 UTC 2005
On Tue, Mar 01, 2005 at 04:36:54PM +0000, Catalin Marinas wrote:
> David Roundy <droundy at abridgegame.org> wrote:
> > Large sized repositories (e.g. the linux kernel) can take a long time to do
> > almost anything, and can require unreasonable amounts of RAM. I suspect
> > this won't be a problem, but it's something to consider if you've got a
> > lot of source code.
> One thing came to mind while reading this - are any of the patches
> (the files on disk) already in the current repository modified during
> a merge operation with a parent repository or only the newly added
> patches are modified by the commutation operators?
Yes, only the newly added patches are modified by the merge. This is good
from a safety standpoint, since it means we can write all the new patch
files before modifying the inventory, so as long as the write to the
inventory is performed atomically, we'll have an atomic modification to the
When we implement the hashed inventory idea (which has been discussed on
darcs-devel), we may determine the name of a patch based on a hash of its
contents, at which point we can modify existing patches with the same
degree of safety as we can add new patches, but until that happens, it's
best to avoid modifying patches whenever possible.
> If not, from my understanding of the patch theory, the following can
> Assuming the following patches
> Parent: B A
> A child branches and continues the development with patch c:
> Child: c B A
> When later merging latest developments on the parent tree (C B A),
> the c^-1 patch will be commuted with C so that the child tree becomes:
> Child: C' c B A
> It is my understanding that at this point, (c^-1)' is discarded (or
> not even computed). If "c" is never pushed to the parent repository
> (as it might happen frequently with a tree like Linux where the main
> developers don't use darcs), (c^-1)' will always be computed against
> C, D, E... patches from the parent repository, and thus all the
> patches after branch will always be loaded into memory at a merge
> The different way of doing this would be to determine c' by commuting
> it with C^-1 and the child tree would be (c' C B A), thus modifying
> the existing patch c.
> Are my assumptions correct?
Yes, and a long-time TODO has been to add an option to darcs optimize that
would reorder patches to match the order in a remote repository, precisely
to avoid this sort of situation. It's remained a TODO item simply because
I haven't had need of it, since my repositories aren't that big.
And of course any code that modifies a lot of patches is inherently risky,
so even though it wouldn't be hard to write, I'd have to do it very
carefully, since you'd rather not risk losing your local patches if there's
a power outage or disk full error during the reorder process.
You can work around this by doing a get and a pull to reorder the patches
on your own.
More information about the darcs-users