Re: Marginal features

On Sun, 8 May 2005, David Roundy wrote:

> > How else would you build a repo that merges two subrepos and can still
> > pull new patches from each easily?

> So this is mostly a feature for people/groups who don't plan on merging
> repositories, and then decide later that it would be a good idea.  I've
> never run across this scenario, and am not sure how common it would be, or
> whether it would ever actually be a good idea.

I'm personally in this situation with a project at work. Our CVS
repository has lots of modules, and I'm using darcs to track a few of them
individually, because tracking the whole lot would be a lot more effort
than it's worth at the moment. However, I may find that I end up needing
to do this, at which point I'll have to merge the repos.

> If each of the repos had all of their contents stored within a
> subdirectory, you could do this without a special feature.  In other words,
> if you plan ahead, you don't need a special "root directory" feature,
> although you have to deal with the fact that in each of the individual
> repos everything's in a subdirectory.

I can't do this in my situation, because I have to have a particular
directory layout to be able to build, and the extra layer of subdirectory
would break that.

> > > > [convergence - merging identical patches]
> > >
> > > 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."
> >
> > If we had two independent repos A and B that converged on the same tree
> > into C, and then there were future patches in say A, could they be pulled
> > into C without causing further conflicts?
>
> There would be future conflicts if repos A and B refuse to pull the
> conflict resolution patch.  But I'm not sure why they'd do that, and if you
> have developers that don't communicate, you've got more serious conflicts
> than those that show up in repository C.

That wasn't the precise scenario I was thinking of, it was just the
easiest way to explain it. In fact I have a few real use cases for a
feature that avoided future conflicts:

 - Two different people convert a CVS repository and do lots of work
independently, then want to merge up. The nicest way of doing that would
be to find the latest point in the history where the two coincided, do the
trivial merge (between two repositories that only had the history up to
that point) and then merge other changes one patch at a time by going via
a copy of that repository (or alternatively have both sides pull from the
merger repository and then merge with each other directly, but this has
the same problem with conflicts at the point they pull from the merger).

 - "Patch replacement". This is something which has come up on the darcs
mailing list when someone wanted to push some changes upstream without
revealing internal development history or patch names - i.e. he wanted to
summarise a whole sequence of patches with a single new patch. With
convergence that is free of future conflicts, it becomes feasible to do
this and still be able to merge future patches to/from upstream, because
you can construct a new patch with identical effects to the old sequence,
then use the trivial merger to provide a staging post for patches going in
either direction, in the same way as above. This also has applications to
the problem of reducing the size of a repository by summarising history
(which has come up with the fptools conversion on the darcs mailing list).

Cheers,

Ganesh