On 22/04/2011 11:29 PM, Darren New wrote:
> On 4/21/2011 13:28, Orchid XP v8 wrote:
>> Every time you try to combine two states of the repo, it creates a new
>> commit object representing the merge.
>
> Just to be clear, adding your changes to my repository is just adding a
> commit. A commit is like a Darcs patch. One update of the repository is
> one commit.
>
> There's a "merge commit" which is nothing but a commit saying "this is
> what it looks like after you merge two commits."

Seems more like because it's so difficult to merge two files, after 
you've done it you have to save it to prevent you having to redo all 
that complex hard work. And in the process, all change application is 
forced to become strictly linear.

Apparently this doesn't stop people working on the Linux kernel. But it 
seems really clumsy to me.

> I'm not sure I'd want to check out something from Darcs that has a
> quarter million patches in it and wait for Darcs to apply them all one
> by one. How well does it handle that?

You're aware that Darcs keeps a cached copy of the latest state of all 
the files, so it doesn't have to recompute them, right?

Last time I tried downloading the repos for GHC, it was dominated by 
network latency. Processor usage was almost non-existent. It just takes 
a long time to shift gigabytes of data over a slow ADSL link. Just as it 
would if I had downloaded a Zip file of the source code with no history 
data at all.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message