[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] solution to the "slow get" problem?
From:       Thomas Zander <zander () planescape ! com>
Date:       2005-04-07 14:01:31
Message-ID: 200504071601.35768.zander () kde ! org
[Download RAW message or body]


On Thursday 07 April 2005 14:59, zooko@zooko.com wrote:
> Imagine that you are helping Andrew Morton try out darcs.  Imagine that
> the first thing you tell him to do is to run "darcs get
> http://kernel.org/linus" to get a copy of Linus's darcs repo.
>
> Oops!  It takes many hours and many hundreds of megabytes.  Andrew loses
> interest in darcs.
>
> Okay, so you don't do that.  Instead you make a .tar.bz2 of Linus's darcs
> repo and you tell Andrew to "wget http://kernel.org/linus.tar.bz2", then
> unpack the tarball and then proceed from there.  Problem solved.  Andrew
> goes on to appreciate the elegance (and speed!) of the common-case
> operations such as "darcs record".
>
> Now why doesn't darcs fetch such a tarball automatically when one types
> "darcs get http://kernel.org/linus"?

2 things;
1) new users should always start with partial repo's
for this to be viable darcs should be able to fetch the missing patches 
after the repo has been initialized. A sort of 'upgrade'
2) even non-partial repos should be build faster.
I woke up this morning thinking that fetching a non-partial repo can be 
build exactly like a partial repo; using the last 'snapshot'  Takes a 
little extra download for that snapshot, but the gain is usually quite big 
while patching.

optimizations of internal workflow (to speed up stuff) are quite important 
at the moment IMO.
-- 
Thomas Zander

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]