Get the Code: Tarball is a sticky mess.

[Vincent Scheib]

We're now state three methods that are all discouraged unless you know things:

- "download straight from SVN (not recommended)",

- "If you know what you're doing, you can alternatively check out the source from git."

- "Using the tarball is usually a bad idea unless you know what you are doing."

Do we still want to promote tarball at all? Perhaps we should move those instructions off this page if it is niche.

---------- Forwarded message ----------
From: The Chromium Projects <nor...@google.com>
Date: Thu, Oct 18, 2012 at 8:36 AM
Subject: [The Chromium Projects] Get the Code was updated
To: sch...@chromium.org

Marc-Antoine Ruel updated the page Get the Code. View the changes below.

Color key: Insertion | Deletion

Contents 1 Bootstrap using the tarball 2 Check out the sources 2.1 Windows 2.2 Mac OS X 2.3 Linux 2.4 Android 3 Check out the source for a specific release 4 Staying Green most of the time 4.1 Chromium continuous build 4.1.1 LKGR 4.1.2 Setup 5 Reducing the size of your checkout 6 Update to the latest revision 7 Checking out subpart of the tree The Chromium codebase consists of hundreds of thousands of files, which means that a checkout straight from the Subversion (SVN) repository can take a long time. To speed up the process, we have provided a tarball that you can use to bootstrap the download. Alternatively, you can skip the tarball and download straight from SVN (not recommended). If you know what you're doing, you can alternatively check out the source from git. Note: There is no advantage to checking out straight from SVN. The tarball includes SVN directories so that after you unpack the tarball, you can get up to the latest revision by using gclient sync. If you just want to see the code without checking it out, you can browse SVN or use Google Code Search for Chromium. If you only want to look at the source code on your own machine, you'll need at least 1.6 GB of hard drive space available. (Somewhat less for Linux, since it already has some of the dependencies installed.) If you want to build it, you will need just under 10 GB of space, including all the object files and executables. Bootstrap using the tarball Warning: Using the tarball is usually a bad idea unless you know what you are doing. Make sure that you have a program that can untar .tgz (.tar.gz) files. Mac OS X and Linux both have tar built in. (On a Mac, use a shell in the Terminal application.) Examples for Windows include the open-source 7-Zip archiver, the free BsdTar utility (part of LibArchive), and WinZip.  Note: Cygwin's tar tool will not work; it will mess up the file permissions. Download the source tarball. Some download applications change the file suffix without extracting the file.  If yours did, rename it back to chromium.rXXXXX.tgz. Choose a directory to hold your source code.  Important: Make sure the directory path has no spaces. Windows example: c:\chromiumtrunk Mac OS X (Terminal) or Linux example: ~/chromium Untar the source tarball into the directory you've chosen. Examples: If you're using 7-Zip, extract the .tgz file, then extract the resulting .tar file. If you're using LibArchive, issue the following command: "C:\Program Files\GnuWin32\bin\bsdtar.exe" -xzf chromium.tgz Install the depot_tools.  If using Ubuntu, see Bootstrap Notes below. Updating your checkout once by running gclient sync --force in the source code directory (~/chromium/src). If you don't want to sync, you need to generate the project files with gclient runhooks. This will call GYP to generate your platform-specific files. You won't be able to build otherwise. If you don't sync, you'll miss some os-specific dependencies so you're better to sync anyway. :) This should give you a complete source tree. But if you have any problems, first check that you've installed any prerequisites listed on the build instructions for your platform. Bootstrap notes for Ubuntu: Make sure your dependencies are up to date by running the install-build-deps.sh script: cd /path/to/chromium/src ./build/install-build-deps.sh  Check out the sources You'll use gclient / depot tools to download the Chromium code from its subversion repository. The first time you execute gclient, there will be a delay (a minute or so) while it updates the depot tools. Downloading the Chromium code takes about an hour. The gclient config <url> step only needs to be run once to set up your working directory.  It creates a .gclient file in your working directory that identifies the corresponding structure to pull from the repository.  The gclient sync step creates several subdirectories.  To update your tree in the future, you only need to run gclient sync from anywhere within your working directory. NOTE: These instructions will pull a read-only tree.  If you are a committer, and plan to make changes to source code, use the instructions given to you when you received commit access. Windows Cygwin: It's easier if you install python, git and subversion first. Otherwise you'll get the depot_tools version which is Windows-native, not cygwin-native. Normal Windows: It's not necessary to have Subversion, Git or Python installed already: the first run of gclient will install them for you. See install depot tools for more info. Create a directory to hold your source code. This example assumes c:\chromiumtrunk, but other names are fine.  Important: Make sure the full directory path has no spaces. In a shell window, execute the following commands: cd c:\chromiumtrunk gclient config https://src.chromium.org/chrome/trunk/src svn ls https://src.chromium.org/chrome and permanently accept the SSL certificate. To download the initial code, update your checkout as described below. Mac OS X Create a directory to hold the code.  This example assumes the directory is ~/chromium, but other names are fine.  Note that if you have FileVault enabled, you'll want to either disable it or put the code in a folder outside the home directory, as otherwise Xcode will be very slow or hang.  You also probably want to disable Spotlight indexing for that folder (System Preferences -> Spotlight -> mark the folder as private). From a shell in the Terminal, execute the following commands: $ cd ~/chromium $ gclient config https://src.chromium.org/chrome/trunk/src $ svn ls https://src.chromium.org/chrome and permanently accept the SSL certificate. To download the initial code, update your checkout as described below. Linux Pick a directory for your build.  We will call this directory $CHROMIUM_ROOT below. Check out Chromium: $ cd $CHROMIUM_ROOT $ gclient config https://src.chromium.org/chrome/trunk/src $ svn ls https://src.chromium.org/chrome and permanently accept the SSL certificate. To download the initial code, update your checkout as described below. Android Follow the general directions for Linux, above. Add Android as the target operating system to your .gclient file.  E.g. solutions = [     { "name"        : "src",       "url"         : "https://git.chromium.org/chromium/src.git",       "deps_file"   : ".DEPS.git",       "managed"     : True,       "custom_deps" : {           },       "safesync_url": "",     }, ] target_os = ['android'] Check out the source for a specific release Use the same steps for "Check out directly from SVN", except that as opposed to using gclient config on https://src.chromium.org/chrome/trunk/src, you need to do a checkout for the specific version of Chromium that you are interested in: For example, if you wanted the source for build 5.0.330.0, the following command would be appropriate: gclient config https://src.chromium.org/chrome/releases/5.0.330.0 Staying Green most of the time When running gclient config, you can specify a second URL to be referenced when doing updates. Instead of pulling the most recent revision, the version number at this URL will be queried, allowing you to track the "most recent green" revision so you can spend less time debugging other people's issues or running builds only to find out that the waterfall was red. Chromium has two of these URLs: Chromium continuous build Get the last revision from: https://commondatastorage.googleapis.com/chromium-browser-continuous/Linux/LAST_CHANGE https://commondatastorage.googleapis.com/chromium-browser-continuous/Mac/LAST_CHANGE https://commondatastorage.googleapis.com/chromium-browser-continuous/Win/LAST_CHANGE This corresponds to the most recent revision that passed both unit tests and layout tests on a particular platform (linux, mac, or win). Since layout tests can take a while to run, this revision may be an hour or more "stale". LKGR https://chromium-status.appspot.com/lkgr This URL holds the version of the latest revision to pass only unit tests (in debug mode). This can happen faster, so for most developers this is probably what you want since it will help you ensure that your changes work against a "fresher" version of Chromium. Setup To use one of these URLs, pass it when you run gclient config:     $ cd ~/chromium     $ gclient config https://src.chromium.org/chrome/trunk/src https://chromium-status.appspot.com/lkgr Now whenever you call gclient sync, it will only sync as far as the configured URL specifies. To over-ride this, pass the --head parameter to gclient, e.g.: gclient sync --head You can also add this directly to your .gclient file if you already have one: solutions = [   { "name" : "src",     "url"  : "https://src.chromium.org/chrome/trunk/src",     "safesync_url" : "https://chromium-status.appspot.com/lkgr"   }, ] Reducing the size of your checkout You can edit your .gclient file to avoid pulling down certain pieces of the checkout that you may not want. For example, inserting something like   "custom_deps": {           "src/third_party/WebKit/LayoutTests": None,     "src/content/test/data/layout_tests/LayoutTests": None,     "src/chrome/tools/test/reference_build/chrome_win": None,     "src/chrome_frame/tools/test/reference_build/chrome_win": None,     "src/chrome/tools/test/reference_build/chrome_linux": None,     "src/chrome/tools/test/reference_build/chrome_mac": None,     "src/third_party/hunspell_dictionaries": None,   }, into one of the solutions (i.e. just underneath the "url": ... line) should save a lot of space. The list of repos that gclient pulls is set in src/DEPS. and listed in .gclient_entries. As of r48011, the following can definitely be removed if you just want to build Chromium: src/third_party/WebKit/LayoutTests - All the WebKit layout tests. src/chrome/tools/test/reference_build/chrome_win - Windows reference build for performance testing. src/chrome_frame/tools/test/reference_build/chrome_win - Chrome Frame reference build for performance testing. src/chrome/tools/test/reference_build/chrome_linux - Linux reference build for performance testing. src/chrome/tools/test/reference_build/chrome_mac - Mac reference build for performance testing. src/third_party/hunspell_dictionaries - spellchecker dictionaries used for unit tests. Update to the latest revision Whether you started with a source tarball or an svn checkout, at some point you'll want to update your checkout to the latest revision. The first time you execute gclient, there will be a delay (a minute or so) while it updates the depot tools. How long the Chromium code update takes depends on how much has changed since you last updated (or since the bootstrap tarball was created). Install the depot_tools, if you haven't already. Visit the Chromium Buildbot waterfall to see the state of the tree.  If the top of the waterfall says: OPEN - The tree is in a good state and you should be able to compile the code. Go to the next step. CLOSED - There might be compile or test failures. You can download the code, but you'll get those same failures when you try to compile or run tests. Best to check back later. In a shell window, execute the following commands: cd [your Chromium source directory] gclient sync To update to a specific revision, use gclient sync --revision src@#### and the DEPS file will make sure you get the other directories in their matching forms. Checking out subpart of the tree Let's say you want to checkout https://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/tutorials/getstarted/, simply run: svn co https://src.chromium.org/chrome/trunk/src/chrome/common/extensions/docs/examples/tutorials/getstarted/ Note the difference in the url, namely /viewvc/chrome was replaced with /svn.

Go to page: Get the Code

-------------
You requested this notification from Google Sites. You can unsubscribe at any time.
Don''t want to get notification of your own changes? Change your settings.

[Mike Frysinger]

why is the tarball bootstrap a bad idea ?  i used it recently (again) and it still worked fine for me.  i unpacked it, ran gclient sync, made some changes, and uploaded them with gcl.  i don't see why those instructions need a "unless you know what you're doing" warning.
-mike

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[John Abd-El-Malek]

On Thu, Oct 18, 2012 at 9:29 AM, Vincent Scheib <sch...@chromium.org> wrote:

We're now state three methods that are all discouraged unless you know things:

- "download straight from SVN (not recommended)",

- "If you know what you're doing, you can alternatively check out the source from git."

- "Using the tarball is usually a bad idea unless you know what you are doing."

Do we still want to promote tarball at all? Perhaps we should move those instructions off this page if it is niche.

I can do a fresh svn checkout in 8 minutes on an SSD (on Windows!).

Do we have stats on how often the tarball is downloaded? i.e. perhaps it's not worth the extra complexity for instructions/generation if it doesn't have a measurable decrease on sever load.

[Dominic Mazzoni]

Anecdotally, I had trouble with the tarball method last time I tried it too. I got it to work, but I had to manually fiddle with it a bit. Someone who doesn't have experience with svn error messages or doesn't understand the subrepository layout could find it confusing.

How does the git workflow compare to svn and tarball, for someone on a slow connection? Should we recommend that?

- Dominic

[Mike Frysinger]

On Thu, Oct 18, 2012 at 12:42 PM, John Abd-El-Malek <j...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 9:29 AM, Vincent Scheib <sch...@chromium.org> wrote:

We're now state three methods that are all discouraged unless you know things:

- "download straight from SVN (not recommended)",

- "If you know what you're doing, you can alternatively check out the source from git."

- "Using the tarball is usually a bad idea unless you know what you are doing."

Do we still want to promote tarball at all? Perhaps we should move those instructions off this page if it is niche.

I can do a fresh svn checkout in 8 minutes on an SSD (on Windows!).

Do we have stats on how often the tarball is downloaded? i.e. perhaps it's not worth the extra complexity for instructions/generation if it doesn't have a measurable decrease on sever load.

well, obvious retorts: not everyone has an awesome network connection nor awesome hardware.  the latter issue isn't as much of a stickler as the former.  the tarball d/l is dirt trivial to resume a partial fetch.

-mike

[Mike Frysinger]

the git workflow is actually worse :(.  the biggest offender is the webkit repo due to its multi-gigabyte size, and due to git itself not being able to resume partial fetches.

-mike

[Jochen Eisinger]

We could probably create another WebKit mirror that doesn't have LayoutTests at all. I think WebKit_trimmed still has the LayoutTests?

-jochen

[John Abd-El-Malek]

On Thu, Oct 18, 2012 at 9:47 AM, Mike Frysinger <vap...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 12:42 PM, John Abd-El-Malek <j...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 9:29 AM, Vincent Scheib <sch...@chromium.org> wrote:

We're now state three methods that are all discouraged unless you know things:

- "download straight from SVN (not recommended)",

- "If you know what you're doing, you can alternatively check out the source from git."

- "Using the tarball is usually a bad idea unless you know what you are doing."

Do we still want to promote tarball at all? Perhaps we should move those instructions off this page if it is niche.

I can do a fresh svn checkout in 8 minutes on an SSD (on Windows!).

Do we have stats on how often the tarball is downloaded? i.e. perhaps it's not worth the extra complexity for instructions/generation if it doesn't have a measurable decrease on sever load.

well, obvious retorts: not everyone has an awesome network connection

in that case, the ~2gb tarball is going to be tough as well ;) 

nor awesome hardware.

trying to compile and link chrome on slow hardware is very painful.

I think the reality is Chrome is such a large project that it's hard to work on it without beefy hardware.

[Nicolas Sylvain]

On Thu, Oct 18, 2012 at 9:42 AM, Dominic Mazzoni <dmaz...@chromium.org> wrote:

Anecdotally, I had trouble with the tarball method last time I tried it too. I got it to work, but I had to manually fiddle with it a bit. Someone who doesn't have experience with svn error messages or doesn't understand the subrepository layout could find it confusing.

I'd be interested in those cases.  I don't think anything changed in the recent past, and we still think the tarball is a good way of getting the source... even for people who don't know what they are doing.  

If you or anyone notice a problem with the tarball, please file a bug and label it build-infrastructure and we'll take a look.

Nicolas

[Ryan Sleevi]

On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org> wrote:

why is the tarball bootstrap a bad idea ?  i used it recently (again) and it still worked fine for me.  i unpacked it, ran gclient sync, made some changes, and uploaded them with gcl.  i don't see why those instructions need a "unless you know what you're doing" warning.
-mike

Unless you know the magic incantations (and they change based on situation), the tarball can regularly break whenever there is a library that is changed via DEPS (eg: used to be checked in and moved to DEPS or vice-versa).

The tarball method has fundamentally the same issues when someone gets 10,000 revisions behind - changes that may have been multiphase (land here, wait X days, land here, wait Y days, remove original change) are collapsed in weird and awkward ways.

Regenerating the tarball regularly (every 1000 revisions?) is one way to reduce the window of this, but it doesn't help anyone who downloaded/mirrored the old tarball, and it creates a lot of churn generating the tarballs.

I'm a fan of removing the tarball as a recommended method, as it still seems to be a source of problems for people judging by IRC, and through no fault of their own.

[Nico Weber]

+1 to what rsleevi says.

[Nicolas Sylvain]

On Thu, Oct 18, 2012 at 10:03 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org> wrote:

why is the tarball bootstrap a bad idea ?  i used it recently (again) and it still worked fine for me.  i unpacked it, ran gclient sync, made some changes, and uploaded them with gcl.  i don't see why those instructions need a "unless you know what you're doing" warning.
-mike

Unless you know the magic incantations (and they change based on situation), the tarball can regularly break whenever there is a library that is changed via DEPS (eg: used to be checked in and moved to DEPS or vice-versa).

We regenerate the tarball nightly and fix those problems as they appear.  It is really not a lot more likely to have those problems with the tarball versus normal gclient checkout.

 

The tarball method has fundamentally the same issues when someone gets 10,000 revisions behind - changes that may have been multiphase (land here, wait X days, land here, wait Y days, remove original change) are collapsed in weird and awkward ways.

Again, updated nightly. 

Regenerating the tarball regularly (every 1000 revisions?) is one way to reduce the window of this, but it doesn't help anyone who downloaded/mirrored the old tarball, and it creates a lot of churn generating the tarballs.

Again.. ;) 

I'm a fan of removing the tarball as a recommended method, as it still seems to be a source of problems for people judging by IRC, and through no fault of their own.

--

[Nico Weber]

On Thu, Oct 18, 2012 at 10:08 AM, Nicolas Sylvain <nsyl...@chromium.org> wrote:
>
>
>
> On Thu, Oct 18, 2012 at 10:03 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>>
>>
>> On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org>
>> wrote:
>>>
>>> why is the tarball bootstrap a bad idea ? i used it recently (again) and
>>> it still worked fine for me. i unpacked it, ran gclient sync, made some
>>> changes, and uploaded them with gcl. i don't see why those instructions
>>> need a "unless you know what you're doing" warning.
>>> -mike
>>
>>
>>
>> Unless you know the magic incantations (and they change based on
>> situation), the tarball can regularly break whenever there is a library that
>> is changed via DEPS (eg: used to be checked in and moved to DEPS or
>> vice-versa).
>
> We regenerate the tarball nightly

Is that new(ish)? I've definitely seen several people on irc running
into the problems rsleevi described.

[Nicolas Sylvain]

On Thu, Oct 18, 2012 at 10:12 AM, Nico Weber <tha...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 10:08 AM, Nicolas Sylvain <nsyl...@chromium.org> wrote:
>
>
>
> On Thu, Oct 18, 2012 at 10:03 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>>
>>
>> On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org>
>> wrote:
>>>
>>> why is the tarball bootstrap a bad idea ?  i used it recently (again) and
>>> it still worked fine for me.  i unpacked it, ran gclient sync, made some
>>> changes, and uploaded them with gcl.  i don't see why those instructions
>>> need a "unless you know what you're doing" warning.
>>> -mike
>>
>>
>>
>> Unless you know the magic incantations (and they change based on
>> situation), the tarball can regularly break whenever there is a library that
>> is changed via DEPS (eg: used to be checked in and moved to DEPS or
>> vice-versa).
>
> We regenerate the tarball nightly

Is that new(ish)? I've definitely seen several people on irc running
into the problems rsleevi described.

It's not new that we create daily tarballs, but we've had bad problems this summer and it got stale for like a month.  We've had stable daily tarballs every day since the end of August.

Nicolas

[John Abd-El-Malek]

Is the primary reason that we have tarballs to decrease svn server load or to reduce checkout time?

If the former, can you share how often it gets downloaded?

[Nicolas Sylvain]

On Thu, Oct 18, 2012 at 10:16 AM, John Abd-El-Malek <j...@chromium.org> wrote:

Is the primary reason that we have tarballs to decrease svn server load or to reduce checkout time?

Both 

If the former, can you share how often it gets downloaded?

We moved everything to google storage. I've never had to find download stats there, but I'll take a look 

Nicolas

[Mikhail Naganov]

I remember several complaints from people on slow connections, that
trying to fetch even the trimmed WebKit git repository takes an
enormous amount of time, and it's impossible to exclude layout tests
from downloading. So using a tarball seems like a better alternative
for them.

[Mike Frysinger]

On Thu, Oct 18, 2012 at 1:03 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org> wrote:

why is the tarball bootstrap a bad idea ?  i used it recently (again) and it still worked fine for me.  i unpacked it, ran gclient sync, made some changes, and uploaded them with gcl.  i don't see why those instructions need a "unless you know what you're doing" warning.

Unless you know the magic incantations (and they change based on situation), the tarball can regularly break whenever there is a library that is changed via DEPS (eg: used to be checked in and moved to DEPS or vice-versa).

The tarball method has fundamentally the same issues when someone gets 10,000 revisions behind - changes that may have been multiphase (land here, wait X days, land here, wait Y days, remove original change) are collapsed in weird and awkward ways.

knocking the tarball method for failures that exist in the standard gclient sync method doesn't seem like a valid reason for demoting the tarball method

-mike

[Ryan Sleevi]

It's being pragmatic.

We should want it to be as dead simple, and as perfectly obvious, for
new contributors to get started writing code. Every hurdle to "getting
started" is one more reason that someone with a great patch, or a real
bug, will end up never contributing to Chromium. This is painfully
clear on Windows, where supporting the "default" toolchain (2005,
2008) required an increasing number of Visual Studio and toolchain
patches to "get it right".

The tarball, in my experience, has a higher failure rate than gclient,
judging simply by the number of questions to (chromium-dev,
chromium-discuss, #chromium). Failures that, at the minimum, are not
easily solved nor explained, and which typically require getting on
IRC and hoping someone will be around to help you through it.

I'm very sympathetic to the problem Vincent originally raised, and to
the work being done by the infrastructure team, which is to ensure
that there is One True Way and that it's clear for people getting
started, and I think the tarball, while useful, makes it harder
overall for people without any experience in the Chromium toolchain,
rather than easier.

[Ryan Hamilton]

+1 for a "One True Way" regardless of what that way is.  I remember being confused and annoying that the getting started instructions had multiple choice sections :>

Cheers,

Ryan

[Peter Kasting]

On Thu, Oct 18, 2012 at 10:39 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

I think the tarball, while useful, makes it harder

overall for people without any experience in the Chromium toolchain,
rather than easier.

+1.

IMO the instructions should basically be "Choose whether you will be using svn or git.  Based on this choice, here is how you check out the code."  Then remove all the "unless you know what you're doing" comments.

If someone has serious problems checking the code out this way, they're going to have serious problems staying up-to-date with the Chrome tree and submitting patches.

PK

[Mike Frysinger]

On Thu, Oct 18, 2012 at 1:39 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Thu, Oct 18, 2012 at 10:25 AM, Mike Frysinger <vap...@chromium.org> wrote:
>> On Thu, Oct 18, 2012 at 1:03 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>> On Thu, Oct 18, 2012 at 9:38 AM, Mike Frysinger <vap...@chromium.org>
>>> wrote:
>>>> why is the tarball bootstrap a bad idea ? i used it recently (again) and
>>>> it still worked fine for me. i unpacked it, ran gclient sync, made some
>>>> changes, and uploaded them with gcl. i don't see why those instructions
>>>> need a "unless you know what you're doing" warning.
>>>
>>> Unless you know the magic incantations (and they change based on
>>> situation), the tarball can regularly break whenever there is a library that
>>> is changed via DEPS (eg: used to be checked in and moved to DEPS or
>>> vice-versa).
>>>
>>> The tarball method has fundamentally the same issues when someone gets
>>> 10,000 revisions behind - changes that may have been multiphase (land here,
>>> wait X days, land here, wait Y days, remove original change) are collapsed
>>> in weird and awkward ways.
>>
>> knocking the tarball method for failures that exist in the standard gclient
>> sync method doesn't seem like a valid reason for demoting the tarball method
>

> It's being pragmatic.
>
> We should want it to be as dead simple, and as perfectly obvious, for
> new contributors to get started writing code. Every hurdle to "getting
> started" is one more reason that someone with a great patch, or a real
> bug, will end up never contributing to Chromium. This is painfully
> clear on Windows, where supporting the "default" toolchain (2005,
> 2008) required an increasing number of Visual Studio and toolchain
> patches to "get it right".
>
> The tarball, in my experience, has a higher failure rate than gclient,
> judging simply by the number of questions to (chromium-dev,
> chromium-discuss, #chromium). Failures that, at the minimum, are not
> easily solved nor explained, and which typically require getting on
> IRC and hoping someone will be around to help you through it.
>
> I'm very sympathetic to the problem Vincent originally raised, and to
> the work being done by the infrastructure team, which is to ensure
> that there is One True Way and that it's clear for people getting
> started, and I think the tarball, while useful, makes it harder
> overall for people without any experience in the Chromium toolchain,
> rather than easier.

if git can be fixed to do resumes of partial clones, then it will be
an acceptable replacement for the tarball. but w/out that, being
pargmatic means supporting people who have flaky network connections
(either the last mile or to google infrastructure) which is absolutely
not feasible with git today. otherwise you cut off large populations
of potential contributors such as asia and south america.
-mike

[Peter Kasting]

On Thu, Oct 18, 2012 at 11:25 AM, Mike Frysinger <vap...@chromium.org> wrote:

if git can be fixed to do resumes of partial clones, then it will be

an acceptable replacement for the tarball.  but w/out that, being
pargmatic means supporting people who have flaky network connections
(either the last mile or to google infrastructure) which is absolutely
not feasible with git today.  otherwise you cut off large populations
of potential contributors such as asia and south america.

Or you could use svn.

PK

[Mike Frysinger]

svn itself is not that great when it comes to flaky connections, but
it is better than git

i also guess you also plan on supporting indefinitely a git->svn
mirror once chromiume finally finishes the migration ?
-mike

[Thiago Farina]

svn is dammit slow and awkward. Why keeps recommending it?

www.youtube.com/watch?v=4XpnKHJAok8

--
Thiago

[Peter Kasting]

On Thu, Oct 18, 2012 at 11:30 AM, Mike Frysinger <vap...@chromium.org> wrote:

i also guess you also plan on supporting indefinitely a git->svn

mirror once chromiume finally finishes the migration ?

We'll cross that bridge when we come to it.

PK 

[Peter Kasting]

On Thu, Oct 18, 2012 at 11:32 AM, Thiago Farina <tfa...@chromium.org> wrote:

svn is dammit slow and awkward. Why keeps recommending it?

The context here is as a specific, currently-supported alternative for a particular case that's apparently problematic for git.

Beyond that, I have no interest in this thread turning into a VCS popularity contest.  Use whatever you want.

PK 

[Nicolas Sylvain]

This has never been in the plans.  I doubt this is something we'll really be doing. We'll probably end up doing something similar to other big git projects and have a bootstrap git tarball.

Nicolas

-mike

[Mike Frysinger]

On Thu, Oct 18, 2012 at 2:35 PM, Peter Kasting <pkas...@google.com> wrote:
> On Thu, Oct 18, 2012 at 11:32 AM, Thiago Farina <tfa...@chromium.org>
> wrote:
>> svn is dammit slow and awkward. Why keeps recommending it?
>
> The context here is as a specific, currently-supported alternative for a
> particular case that's apparently problematic for git.

no it's not. the tarball method is for people who have crap
connections to google's hosting locations. the vcs in use makes a
difference as to how much pain we want to live with in order to stop
supporting the tarball method, but the conception of the tarball
method itself had nothing to do with git.
-mike

[Mike Frysinger]

On Thu, Oct 18, 2012 at 2:36 PM, Nicolas Sylvain <nsyl...@chromium.org> wrote:
> On Thu, Oct 18, 2012 at 11:30 AM, Mike Frysinger <vap...@chromium.org>
> wrote:
>> On Thu, Oct 18, 2012 at 2:27 PM, Peter Kasting <pkas...@chromium.org>
>> wrote:
>> > On Thu, Oct 18, 2012 at 11:25 AM, Mike Frysinger <vap...@chromium.org>
>> > wrote:
>> >> if git can be fixed to do resumes of partial clones, then it will be
>> >> an acceptable replacement for the tarball. but w/out that, being
>> >> pargmatic means supporting people who have flaky network connections
>> >> (either the last mile or to google infrastructure) which is absolutely
>> >> not feasible with git today. otherwise you cut off large populations
>> >> of potential contributors such as asia and south america.
>> >
>> > Or you could use svn.
>>
>> svn itself is not that great when it comes to flaky connections, but
>> it is better than git
>>
>> i also guess you also plan on supporting indefinitely a git->svn
>> mirror once chromiume finally finishes the migration ?
>
> This has never been in the plans. I doubt this is something we'll really be
> doing. We'll probably end up doing something similar to other big git
> projects and have a bootstrap git tarball.

i was being semi-sarcastic in pointing out that "use svn" is not a
long (or even short) term answer
-mike

[Pierre-Antoine LaFayette]

In my experience of getting the source code from outside of Google, I've long given up the hope that you can download the source and be up and running in less than a few hours. Usually I just do the full git checkout, then go do something to kill the time (like sleep through the night). It's likely not mission critical for outside contributors to have to wait a few hours or overnight to start building and working on Chromium code. That being said, checking out the Chromium code is pretty painful in general. The tarball option a good option if you want to get the code as fast as possible.

I agree with Peter's choose your own adventure wiki suggestion. Select Git or SVN and do the following would be a lot clearer for newcomers.

--

[Thiago Farina]

On Thu, Oct 18, 2012 at 3:39 PM, Pierre-Antoine LaFayette
<pierre.l...@gmail.com> wrote:
> In my experience of getting the source code from outside of Google, I've
> long given up the hope that you can download the source and be up and
> running in less than a few hours.

Once you checkout it, is not a problem to keep up to date.

Yes, doing a checkout from scratch really takes half a day in slow
connections. But after that, then you don't have anything to worry
about.

--
Thiago