Accidently I have misused tailor and ended up creating a new tree instead adding 
the changes to the existing one.
The initial patch of the new tree is 21mb small and if I try to push or pull it 
to the old one CPU usage goes to 99% and memory usage to 75% (2GB of memory 
used). It sits there for many many hours without being able to apply the patch.
Actually the merging of these two tree should not bring any errors as they are 
only one revision away from each other.
If you want to try it I can give you the URLs of the two trees.

Quoting Holger Freyther <bugs@darcs.net>:

>
> New submission from Holger Freyther <freyther@handhelds.org>:
>
> Accidently I have misused tailor and ended up creating a new tree instead
> adding
> the changes to the existing one.
> The initial patch of the new tree is 21mb small and if I try to push or pull
> it
> to the old one CPU usage goes to 99% and memory usage to 75% (2GB of memory
> used). It sits there for many many hours without being able to apply the
> patch.
> Actually the merging of these two tree should not bring any errors as they
> are
> only one revision away from each other.
> If you want to try it I can give you the URLs of the two trees.

The URLs would certainly be handy for checking.  I think I know what is going
wrong here. If I'm right, then fixing this would require an extensive rewrite
of some of the data handling code.  Hopefully I'm wrong and you're hitting a
corner case that can be fixed more easily.

Not sure when would be able to look at this though.

Thanks,
Jason

The two tress can be found on:
http://ewi546.ewi.utwente.nl/OE/other_scms/darcs/ The .orig tree contains the 
changes until the 11ntg of january and the .new tree contains all changes since 
then.
My naive expecatation is I can pull the .new tree back into the .orig tree. Due 
the nature of the tailor conversion this pull should be even conflict free and 
it should be a simple merge.

On Wed, Feb 01, 2006 at 05:16:52PM +0000, Holger Freyther wrote:
> Accidently I have misused tailor and ended up creating a new tree instead adding 
> the changes to the existing one.
> The initial patch of the new tree is 21mb small and if I try to push or pull it 
> to the old one CPU usage goes to 99% and memory usage to 75% (2GB of memory 
> used). It sits there for many many hours without being able to apply the patch.
> 
> Actually the merging of these two tree should not bring any errors as they are 
> only one revision away from each other.

This is not how darcs works.  Every repo starts with an empty
tree.  The first patch in each of your repos populates this
empty three with lots of dirs and files.  They are not the
same patch.  They both need an empty tree to perform their
changes on, because that's how they were constructed during
recording.  And when they meet they will fight badly about
every little file and dir they both want to to put in the
empty tree.  There will be no winner and the result will be
sort of undecided, which causes further problems for patches
that follows with changes to these files.  You can't use
darcs to merge versions like this.  Even if darcs eventually
completes, the result will not be what you wish for.

What you could do is replay the changes from repo.new one
by one and record them as new patches in repo.old.  It is
scriptable, but I think move and replace patches get lost
(turns into rm/add and hunks) this way.

On Fri, Feb 03, 2006 at 09:59:09AM +0000, Holger Freyther wrote:
> My naive expecatation is I can pull the .new tree back into the .orig
> tree. Due the nature of the tailor conversion this pull should be even
> conflict free and it should be a simple merge.

Tommy's right.  This isn't going to work like you expect.  Everything will
conflict, and the result will not be desirable, even if it were to complete
(which it probably won't).
-- 
David Roundy
http://www.darcs.net

Well, from a naive point of view I have a linearized history with rev0,rev1,...
Now I have rev0 to rev1300 in one tree and rev1301.. in another one.

If I'm in the tree with rev1300 and applying the patch of rev1301 no conflicts
should be created as well. From a user point of view I do not see any reason why 
this should not work. From a implementation point of view I see the issue now.

Somehow git, svk, hg are quite well capable of handling this situation (e.g hg 
warns about merging two foreign trees). 
Anyway as this is not the way darcs is working and this is likely to be not a 
typical use case I guess when can close this issue.

Could you please give me a hint on how to replay the change (e.g. which commands 
it involves)

On Sun, Feb 05, 2006 at 11:29:46PM +0000, Holger Freyther wrote:
> Well, from a naive point of view I have a linearized history with
> rev0,rev1,...  Now I have rev0 to rev1300 in one tree and rev1301.. in
> another one.

Darcs doesn't store a sequence of versions, it stores a sequence of
changes, and the second tree has one big change that conflicts with all the
changes in the first tree.

> Somehow git, svk, hg are quite well capable of handling this situation
> (e.g hg warns about merging two foreign trees).  Anyway as this is not
> the way darcs is working and this is likely to be not a typical use case
> I guess when can close this issue.

This is because git, svk, etc are all version-based, not change-based.

> Could you please give me a hint on how to replay the change (e.g. which
> commands it involves)

To get a sequence of trees, you could pull one patch at a time into an
empty repository.  But really, this is the sort of work that tailor is
designed to handle, so that's what I'd recommend using (although I'm not
sufficiently familiar with tailor to know how exactly to do this).
-- 
David Roundy
http://www.darcs.net