[darcs-users] Tips on a large merge, the big "initial import" takes forever

[Nicolas Pouillard]

Excerpts from David Roundy's message of Wed Jan 30 22:44:27 +0100 2008:
> On Tue, Jan 29, 2008 at 12:15:42PM +0000, Matthew Bloch wrote:
> > I'm trying to start a long-overdue merge of 9 months worth of changes -
> > an external developer branched some old code into svn, worked on it
> > quite a lot, and now he's finished I would like to merge it back to my
> > darcs repo, i.e. in ascii art form:
> > 
> > + my darcs repo, April 2007
> > |
> > +----+ $dev1 copies repository, imports whole lot to svn
> > |    |
> > +    +
> > |    | lots of check-ins on both svn & darcs branches
> > +    + ...
> > |    |
> > +    +
> > |    |
> > ? <--/ svn rvn 106, Matt converts back to darcs with tailor
> > |
> > |
> > 
> > I've used tailor to convert his repo to darcs format, it looks
> > convincing, the problem concerns that very first patch to the svn
> > repository.
> > 
> > When I try to "darcs pull" that big import, darcs just chews on CPU for
> > 24hrs (as long as I've left it) and I've no idea when or whether it is
> > likely to finish.  I presume eventually it would decide there were no
> > changes to make because our sources will be identical at the same date,
> > but even if it's the right thing to do, I can't include a "CPU killer"
> > patch which will freeze up for every single other merge that will need
> > doing (probably 5 or 6).
> >
> > What I would like to do really is chuck away revision 1 from the
> > converted svn repo, and "patch in" the darcs revision from which svn
> > revision 1 was originally imported.  Then the pull wouldn't have to
> > consider the giant patch at the start.
> 
> Yes, that's what you need to do.  I am sure tailor can do that, but don't
> know how.  It sounds like what you're doing right now is trying to merge
> two unrelated repositories that have 100% conflicting patches.  Darcs isn't
> going to be able to do this.  If you construct two repositories with shared
> history, then it should be no problem at all.  So it all comes down to
> convincing tailor that that first commit isn't a change at all, and that
> the initial state of the svn repository includes all the prior darcs
> history.

That's  a  case  where having some kind disjunctive tag point in history could
be good (what's hell is that thing...).

Let's  imagine  that  one  can  extend  "a  posteriori" a darcs tag, by giving
another history that ends-up in the same context.

So  instead  of  having  just  patches  as  dependencies,  a  tag  could  have
alternatives of patches.

That's  currently  just  a  rough  idea,  but  I  really  think  that a lot of
interesting use cases wait behind this.

For  instance  that would provide a better way for representing checkpoints. A
checkpoint  will  be  an alternative history (as one single big patch), to the
classical history.

This  also  would help people trying to incrementally convert their history. A
team  could  start  using darcs by importing a snapshot of their project (as a
few  patches),  instead  of  converting  history.  Indeed  for  some  reasons,
converting  history  can  be  harder  than  expected. So this team could start
patching, and then later on, plug their old history back.

Any thoughts about this?

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080130/58e26440/attachment.pgp