Re: [darcs-users] Re: [BK] upgrade will be needed

[Dustin Sallings]

On Feb 18, 2005, at 1:09, Andrea Arcangeli wrote:

> darcs scares me a bit because it's in haskell, I don't believe very 
> much
> in functional languages for compute intensive stuff, ram utilization

	It doesn't sound like you've programmed in functional languages all 
that much.  While I don't have any practical experience in Haskell, I 
can say for sure that my functional code in ocaml blows my C code away 
in maintainability and performance.  Now, if I could only get it to 
dump core...

	Haskell was a draw for me.  It's very rare to find someone who 
actually knows C and can write bulletproof code in it.

> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>
> The advantage it will provide is that it'll be compact and a backup 
> will
> compress at best too. Small compressed tarballs compress very badly
> instead, it wouldn't be even comparable. Once the thing is very compact
> it has a better chance to fit in cache, and if it fits in cache
> extracting diffs from each file will be very fast. Once it'll be 
> compact
> the cost of a changeset will be diminished allowing it to scale better
> too.

	Then what gets transferred over the wire?  The full modified ,v file?  
Do you need a smart server to create deltas to be applied to your ,v 
files?  What do you do when someone goes in with an rcs command to 
destroy part of the history (since the storage is now mutable).

	I use both darcs and arch regularly.  darcs is a lot nicer to use from 
a human interface point of view (and the merging is really a lot 
nicer), but the nicest thing about arch is that a given commit is 
immutable.  There are no tools to modify it.  This is also why the 
crypto signature stuff was so easy to fit in.

	RCS and SCCS storage throws away most of those features.

--
Dustin Sallings

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/