Date: Wed, 31 Aug 2011 18:13:19 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: perryh@pluto.rain.com Cc: uqs@spoerlein.net, kmacy@freebsd.org, fullermd@over-yonder.net, freebsd-arch@freebsd.org Subject: Re: Official git export Message-ID: <CAGH67wTr7sTGsFci2wmtdH5iV5STtTy=MPPnyMRgP7X6sy%2B%2B8g@mail.gmail.com> In-Reply-To: <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com> References: <CAMBSHm8uX45k0M4on=5Cpw_CKoddA=4oJSNXpH7dGPt=Vy2HOw@mail.gmail.com> <alpine.BSF.2.00.1108261000040.48200@fledge.watson.org> <slrnj5lc58.jd1.vadim_nuclight@kernblitz.nuclight.avtf.net> <4e5ba9c3.bzHIw1KEy8R2QcK7%perryh@pluto.rain.com> <3420B331-C697-468A-80BA-B31C33804710@freebsd.org> <4e5c5b5f.moT7dLemOuteQJ5T%perryh@pluto.rain.com> <4E5C364D.7070904@freebsd.org> <CAHM0Q_Mq3YEEpB6uNymjtd=WCQuTR6gd=71EsLxJf5J0ygyjiw@mail.gmail.com> <20110830201357.GB58638@acme.spoerlein.net> <4e5e458a.Un%2BVK0itRgItvxbf%perryh@pluto.rain.com> <20110831081815.GN2493@over-yonder.net> <4e5f2e26.6PQ5d6F3eauFfAcH%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 1, 2011 at 12:03 AM, <perryh@pluto.rain.com> wrote:
> "Matthew D. Fuller" <fullermd@over-yonder.net> wrote:
>> On Wed, Aug 31, 2011 at 07:30:34AM -0700 I heard the voice of
>> perryh@pluto.rain.com, and lo! it spake thus:
>> > Surely it would be "noticeably faster" to _download_ only (say)
>> > /usr/src/sys than all of /usr/src, unless one has an uncommonly
>> > fast link? =A0(It would also impose less load on the serving site.)
>>
>> In the context of most current-gen DVCSen, it's unlikely to be much
>> (or in fact _any_) faster or less data to transfer. =A0It's just less
>> data to blat into the working tree.
>
> That makes a certain amount of sense _if_ the VCS considers the
> entire base system to reside in a single repository, which is why
> someone was suggesting splitting it into multiple repositories.
>
> The question remains: =A0does it really make sense that I must download
> the entire VCS history for things like cddl, contrib, crypto, games,
> and kerberos if I only plan to work on the kernel?
Which is part of the point of modularized (aka componentized by
some groups) VCSs. The problem is that you push revisioning //
management of the VCSs into components, which might carry its own set
of problems when you update revisions of components and there's a
ripple effect with what needs to be updated across all components
(which in and of itself becomes a management nightmare).
Thanks!
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wTr7sTGsFci2wmtdH5iV5STtTy=MPPnyMRgP7X6sy%2B%2B8g>