Re: Marginal features

On Fri, May 06, 2005 at 09:05:44PM -0700, Bram Cohen wrote:
> Then there are the marginal features, which might or might not be good
> ideas, here are some of them -
> 
> moving the root - the easiest way to provide directory rename
> functionality is to treat the root as special. We implemented it this way
> in Codeville, and didn't think much of it, but it turns out that
> precisely this functionality is needed to import one project into another
> one as a subdirectory, so we now think this functionality is a good idea
> and will be supporting it in the future

I've thought about this (and even talked about it), but it never seemed
like it would be worth implementing.  Darcs always stores filenames with a
preceding ./ partly so we could perhaps later "rename" the root to be
something like subproject/, but I never could convince myself that this
would actually be useful.  Nor did I figure out how exactly it would work.

> Anyhow, cutting in half and sewing together are somewhat more reasonable
> in principle than copy and un-copy. With a weave, sewing together is
> restricted in that only one of the two orders of sewing together can be
> supported, but with our fancy clumping weave ordering algorithm the A then
> B version is supported quite well. Perhaps there could be a command to sew
> together two files and have the system pick the order. Cutting in half
> doesn't have the same problem, because you can place the two halves in the
> correct places. There is a fair amount of complexity added by this
> functionality though, and its usage in the real world is quite rare, so
> for now it's in the 'probably not' pile.

Agreed, splitting and suturing would be reasonable (unlike copy and merge).
I can see that they'd also be reasonably common, probably about as common
as darcs replace is used.  In refactoring code one often wants to move code
from multiple files into a single file, or the other way around.  In the
absense of hunk move patches, I'm not sure how useful it would actually be,
though, since you'd probably very often follow the suture with a reordering
of the functions to make sense.  Still, it might be nice...

> convergence - If two people apply the same patch from outside of the
> system, it would be nice if applications of that patch were treated as the
> same thing, which would happen if they were both done within the same
> version control system. Likewise if two people do an initial checkin of
> the same stuff it would be nice if their projects could simply merge
> together cleanly as if they started from the same initial checkin. This
> functionality is quite fragile though (initial checkins may be of slightly
> different versions, patches applied have to be *identical*) and it's quite
> technically difficult to support, so for now not only doesn't Codeville
> have much of this, but what little it does have is probably going away.

This is a common complaint about darcs, and is a tough problem.  I think
the best solution is to *not* treat the patches as having identical
identities, but in the conflict resolution to recognize what the user has
tried to do and suggest a default "trivial" resolution.  I'd like to have a
distinction in a future darcs between "unresolved conflicts" and "resolved
conflicts".  The latter would be actual conflicts, but ones for which darcs
was able to suggest a reasonable resolution.  Thus "identical" patches
would fall into the latter category.  It'd still be a conflict and would
require a resolution patch, but the user would get a nice message like "We
were able to resolve 5 conflicts in foo.cpp, please record if this is
satisfactory."
-- 
David Roundy
http://www.darcs.net