[Top][All Lists]
[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
signature.asc
Description: Digital signature
- [Gnu-arch-users] Google Summer of Code, Andy Tai, 2006/04/18
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/18
- Re: [Gnu-arch-users] Google Summer of Code, Ludovic Courtès, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code,
James Blackwell <=
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, James Blackwell, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, James Blackwell, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Aldrik KLEBER, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Stefan Monnier, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Aldrik KLEBER, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Aldrik KLEBER, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20