atom feed192 messages in org.freebsd.freebsd-archRe: Official git export
FromSent OnAttachments
110 earlier messages
Olli HauerAug 28, 2011 12:22 am 
Vadim GoncharovAug 28, 2011 1:11 pm 
Vadim GoncharovAug 28, 2011 1:23 pm 
Vadim GoncharovAug 28, 2011 2:18 pm 
per...@pluto.rain.comAug 29, 2011 1:10 am 
Adrian ChaddAug 29, 2011 2:03 am 
Vadim GoncharovAug 29, 2011 2:53 am 
K. MacyAug 29, 2011 4:50 am 
Philip PaepsAug 29, 2011 5:33 am 
Philip PaepsAug 29, 2011 5:39 am 
selvenAug 29, 2011 7:21 am 
selvenAug 29, 2011 7:43 am 
Qing LiAug 29, 2011 8:02 am 
Matthew D. FullerAug 29, 2011 1:40 pm 
per...@pluto.rain.comAug 29, 2011 2:06 pm 
Julian ElischerAug 29, 2011 6:00 pm 
Matthew D. FullerAug 29, 2011 6:03 pm 
Julian ElischerAug 29, 2011 6:04 pm 
K. MacyAug 29, 2011 6:57 pm 
Benjamin KadukAug 29, 2011 7:24 pm 
K. MacyAug 29, 2011 7:37 pm 
Benjamin KadukAug 29, 2011 7:41 pm 
Максим ГолубAug 29, 2011 8:59 pm 
K. MacyAug 29, 2011 11:40 pm 
per...@pluto.rain.comAug 29, 2011 11:48 pm 
Mark LinimonAug 30, 2011 1:23 am 
Robert WatsonAug 30, 2011 6:37 am 
Ulrich SpörleinAug 30, 2011 1:13 pm 
K. MacyAug 30, 2011 1:20 pm 
Vadim GoncharovAug 30, 2011 2:41 pm 
Vadim GoncharovAug 30, 2011 2:47 pm 
Vadim GoncharovAug 30, 2011 3:04 pm 
Vadim GoncharovAug 30, 2011 3:37 pm 
Mark LinimonAug 30, 2011 5:25 pm 
Alex GoncharovAug 30, 2011 5:44 pm 
per...@pluto.rain.comAug 31, 2011 12:41 am 
Matthew D. FullerAug 31, 2011 1:17 am 
Ulrich SpörleinAug 31, 2011 1:45 am 
K. MacyAug 31, 2011 3:54 am 
Fabien ThomasAug 31, 2011 5:27 am 
per...@pluto.rain.comAug 31, 2011 5:13 pm 
Garrett CooperAug 31, 2011 6:12 pm 
Andriy GaponAug 31, 2011 10:05 pm 
Mark LinimonSep 1, 2011 12:26 am 
per...@pluto.rain.comSep 1, 2011 1:11 am 
Andriy GaponSep 1, 2011 1:53 am 
per...@pluto.rain.comSep 2, 2011 10:13 pm 
Andriy GaponSep 2, 2011 11:46 pm 
Garrett CooperSep 3, 2011 12:17 am 
Peter JeremySep 4, 2011 1:36 am 
selvenSep 8, 2011 12:44 pm 
Miroslav LachmanSep 8, 2011 2:34 pm 
Garrett CooperSep 8, 2011 3:07 pm 
Erik CederstrandOct 25, 2012 2:11 am 
Dag-Erling SmørgravOct 25, 2012 7:38 am 
Erik CederstrandOct 25, 2012 7:56 am 
Chris ReesOct 25, 2012 8:10 am 
Dag-Erling SmørgravOct 25, 2012 8:52 am 
Eitan AdlerOct 25, 2012 11:08 am 
Erik CederstrandOct 25, 2012 11:52 am 
Chris ReesOct 25, 2012 12:02 pm 
Eitan AdlerOct 25, 2012 12:09 pm 
Gary PalmerOct 25, 2012 12:30 pm 
Eitan AdlerOct 25, 2012 12:42 pm 
Erik CederstrandOct 25, 2012 1:07 pm 
Eitan AdlerOct 25, 2012 1:15 pm 
Erik CederstrandOct 25, 2012 2:09 pm 
Dag-Erling SmørgravOct 26, 2012 12:54 am 
Erik CederstrandOct 27, 2012 7:55 pm 
Peter WemmOct 27, 2012 10:25 pm 
Erik CederstrandOct 28, 2012 12:20 pm 
Eitan AdlerOct 28, 2012 8:35 pm 
Peter JeremyOct 30, 2012 1:28 am 
Erik CederstrandOct 30, 2012 3:06 am 
Adrian ChaddOct 30, 2012 8:50 am 
Erik CederstrandOct 30, 2012 9:44 am 
Peter WemmOct 30, 2012 10:27 am 
Peter WemmOct 30, 2012 10:38 am 
Eitan AdlerOct 30, 2012 10:46 am 
Garrett CooperOct 30, 2012 5:15 pm 
Erik CederstrandOct 31, 2012 1:14 am 
Dag-Erling SmørgravOct 31, 2012 1:38 am 
Subject:Re: Official git export
From:Peter Jeremy (pete@acm.org)
Date:Sep 4, 2011 1:36:32 am
List:org.freebsd.freebsd-arch

On 2011-Sep-03 05:11:07 -0700, per@pluto.rain.com wrote:

A few hundred MB of disk space is nothing. Having to _download_ a few hundred MB of source code, that one already has, is _not_ "nothing" unless one has a rather large pipe.

If you already have the source code, why would you be downloading it again? Typically, if you keep a local copy of the repo, you would be checking out from it, rather than using csup or similar.

One way to mitigate this would be to provide the ability to download and install VCS metadata (back-deltas, commit comments, etc.) for particular files and directories "as needed".

Based on the description, I'll take "metadata" to mean the VCS repository itself, rather than VCS-related metadata that is added to a checked-out working directory.

Whilst this was fairly easy for CVS, it's not practical for SVN because the metadata is stored per-commit, rather than per-file.

If that level of granularity is problematic, just splitting the metadata into 5 groups would help:

group contents size *

infrastructure all files directly in /usr/src; and 66 MB subdirs etc, include, lib, libexec, release, rescue, share, tools.

contrib /usr/src/contrib 232 MB

crypto /usr/src/{crypto,kerberos5,secure} 40 MB

kernel /usr/src/sys 143 MB

other /usr/src/{bin,cddl,games,gnu, 50 MB sbin,usr.bin,usr.sbin}

I don't believe this is practical given the way FreeBSD and SVN work. From the SVN perspective, it's not practical to disentagle the content in that way. From a FreeBSD perspective, I don't think it'll work - you can't do much without "infrastructure". "contrib" is referenced from "infrastructure" and "other". "crypto" includes some historic (but not current) references to "contrib".

For that matter, FreeBSD could provide the VCS metadata corresponding to each release as a separate ISO, so those who need it can obtain and install it. Those for whom large downloads are a problem could buy it on CD.

Once upon a time, the release CDs did include the CVS tree but it simply became too big. And, since you can checkout any point in history I don't believe having a -release repo CD/DVD adds any real value. You just need a copy of the repo after the relevant release - this can be downloaded via CTM/ftp or csup for CVS and svn can do it's own downloading. My guess is that most people for whom large downloads present a problem know someone who has ready access to the repo and could burn a CD/DVD for them.