gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Google Summer of Code


From: James Blackwell
Subject: Re: [Gnu-arch-users] Google Summer of Code
Date: Wed, 19 Apr 2006 18:31:25 -0400
User-agent: Mutt/1.5.11

On Wed, Apr 19, 2006 at 02:13:09PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Thomas Lord <address@hidden> writes:
> 
> > Aside from SoC, it might be interesting to think out loud a bit about
> > the status
> > of 2.0, though.  Hmm....
> 
> I'd be interested in hearing what we would expect from an Arch 2.0.
> 
> I've somewhat given up following the evolution of Free Software DRCS.
> My last conclusions were that most of the new DRCS, roughly, compared to
> Arch 1, (i) significantly improved on storage efficiency and access
> time, but (ii) did not provide remarkable improvements in terms of
> functionality (one notable exception might be merging).
> 
> Is this a relevant summary of the situation?

Nope. There's a number of impressive functionality improvements in the
DRCS world.  Consider repositories/archives (*arch*, bazaar-ng), bisect
(git), plugins (bazaar-ng) and namespace research (gnuarch).

The fly in the ointment is the time & bandwidth it takes to download data.
Mercurial is probably the furthest ahead in addressing this by being smart
about their storage format and how they pull data over the wire. Bazaar-NG
and Monotone are particularly poor at it today.

The hindrance is that all of the drcs's that I can think of today all have
one requirement that devastates DRCS usage in projects with reasonably
sized  histories -- doing any useful work involves downloading all
history.

Not many sane projects are willing to absorb the cost of new users having
to spend anywhere from dozens of minutes to hours to get a copy of a
branch that they can explore and potentially learn to hack.  I'm not aware
of any projects that have solved this problem. At best, they've mitigated
it.

Whats needed in this field is research on how to minimise the requirement
for history and then to delay downloading it until its necessary. There's
some anecdotal proof in the arch world that one can delay getting
information in ancestors until you actually need it.



> Thanks,
> Ludovic.
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
My home page:   <a href="http://jblack.linuxguru.net";>James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]