Problem using release version tag with git checkout

2,617 views
Skip to first unread message

Marshall Greenblatt

unread,
Apr 21, 2014, 7:26:11 PM4/21/14
to chromium-dev
Hi All,

I'm trying to build Chromium at a specific release version using only a git checkout. The checkout was initially created as follows:

>fetch --nohooks chromium --nosvn=True
>gclient sync --nohooks --with_branch_heads

If I checkout refs/tags/VERSION it fails in `gclient sync` [1]. If I checkout refs/remotes/branch-heads/BRANCH it works as expected [2]. These results repeat for all values of VERSION and BRANCH that I've tried.

Is there a way currently to checkout Chromium at a specific release version using only git? I'm aware of the git svn approach described at http://www.chromium.org/developers/how-tos/get-the-code#Working_with_release_branches but would like to avoid using svn if possible.

Thanks,
Marshall


[1]: Using the version tag:

>git checkout refs/tags/35.0.1916.27
Checking out files: 100% (897/897), done.
Previous HEAD position was e6ec8f0... Merge 264451 "Fixes the crash for "learn more" link of the dialo..."
HEAD is now at 4cab0bc... Publish DEPS for Chromium 35.0.1916.27

>gclient sync --nohooks --jobs 16

src (ERROR)
----------------------------------------
[0:00:00] Started.
[0:00:00] ________ unmanaged solution; skipping src
----------------------------------------
Error: 1> Dependency src specified more than once:
1> vs


[2]: Using the branch head:

>git checkout refs/remotes/branch-heads/1916
Checking out files: 100% (897/897), done.
Previous HEAD position was 4cab0bc... Publish DEPS for Chromium 35.0.1916.27
HEAD is now at e6ec8f0... Merge 264451 "Fixes the crash for "learn more" link of the dialo..."

>gclient sync --nohooks --jobs 16
Syncing projects:  98% (87/88), done.

Marshall Greenblatt

unread,
Apr 21, 2014, 7:58:27 PM4/21/14
to chromium-dev
On Mon, Apr 21, 2014 at 7:26 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi All,

I'm trying to build Chromium at a specific release version using only a git checkout. The checkout was initially created as follows:

>fetch --nohooks chromium --nosvn=True
>gclient sync --nohooks --with_branch_heads

If I checkout refs/tags/VERSION it fails in `gclient sync` [1]. If I checkout refs/remotes/branch-heads/BRANCH it works as expected [2]. These results repeat for all values of VERSION and BRANCH that I've tried.

Is there a way currently to checkout Chromium at a specific release version using only git? I'm aware of the git svn approach described at http://www.chromium.org/developers/how-tos/get-the-code#Working_with_release_branches but would like to avoid using svn if possible.

So, it looks like I need the commit immediately before the version tag. Hopefully that will work consistently :/.


  'src':
      '/branches/1916/src@262261',

>git checkout refs/tags/35.0.1916.27
Previous HEAD position was 575d428... Incrementing VERSION to 35.0.1916.27
HEAD is now at 4cab0bc... Publish DEPS for Chromium 35.0.1916.27

>git status
HEAD detached at 35.0.1916.27

>git log -2
commit 4cab0bcf0b3c26ba6ee0ec13847e61793dffe9b6
Author: gitdeps <git...@chromium.org>
Date:   Wed Apr 16 12:51:17 2014 -0700

    Publish DEPS for Chromium 35.0.1916.27

commit 575d4285b1678b31aef67fb87a74840a8718f298
Author: chrome-...@google.com <chrome-...@google.com@0039d316-1c4b-4281-b951-d872f2087c98>
Date:   Tue Apr 8 00:00:50 2014 +0000

    Incrementing VERSION to 35.0.1916.27

    git-svn-id: svn://svn.chromium.org/chrome/branches/1916/src@262261 0039d316-1c4b-4281-b951-d872f2087c98

Marshall Greenblatt

unread,
Apr 21, 2014, 10:20:50 PM4/21/14
to chromium-dev
On Mon, Apr 21, 2014 at 7:58 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
On Mon, Apr 21, 2014 at 7:26 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi All,

I'm trying to build Chromium at a specific release version using only a git checkout. The checkout was initially created as follows:

>fetch --nohooks chromium --nosvn=True
>gclient sync --nohooks --with_branch_heads

If I checkout refs/tags/VERSION it fails in `gclient sync` [1]. If I checkout refs/remotes/branch-heads/BRANCH it works as expected [2]. These results repeat for all values of VERSION and BRANCH that I've tried.

Is there a way currently to checkout Chromium at a specific release version using only git? I'm aware of the git svn approach described at http://www.chromium.org/developers/how-tos/get-the-code#Working_with_release_branches but would like to avoid using svn if possible.

So, it looks like I need the commit immediately before the version tag. Hopefully that will work consistently :/.

It looks like this won't work after all. The DEPS and .DEPS.git file for the Chromium checkout point to Blink trunk instead of the release branch. For example, http://src.chromium.org/svn/releases/35.0.1916.27/DEPS uses /branches/chromium/1916/public@171002 whereas .DEPS.git at the equivalent git checkout (575d4285b1678b31aef67fb87a74840a8718f298) uses /trunk@170313.

Can anyone shed light on how the releases/*/DEPS file is generated and whether it would be possible to automatically create an equivalent .DEPS.git file?

Alternately, how bad would it be to release a product built with this combination of dependencies (assuming it builds)? Will it be significantly less stable / less tested than the build using the Blink branch?

Primiano Tucci

unread,
Apr 22, 2014, 2:42:21 AM4/22/14
to magree...@gmail.com, chromium-dev
> I'm trying to build Chromium at a specific release version using only a git checkout. 
This is essentially wrong per definition and is not supported. Probably things will change soon(ish), see the thread about migration to Git.
Sadly this question / kind of mistake comes on chromium-dev on a monthly basis. We should probably just improve the docs at this point.

Please note that "working on a release branch" is != "build a release version of chrome".
In general you should need to follow the "working on a release branch" instructions only if you are a committer needing to cherry-pick / mangle something on a release branch and for whatever reason you can't use drover. In any other case, is very unlikely that those instructions will give you anything helpful. In this specific case, for instance, this doesn't seem what you want to do here.

If you want to just build chromium as released for a given release X, the only publicly supported workflow is using SVN as follows:

That's it. Any other workflow will very likely end up with some uncompilable garbage or will just compile a lie.
The reason is that, as you figured out, the DEPS (and .DEPS.git) files in the release branch are pretty much meaningless (they are a snapshot of the DEPS at the branch point).

AFAIK there is no easy way to recreate the .DEPS.git file from a SVN release branch DEPS.
Just use SVN. I can agree that SVN is slow, tedious and [any other adjective ad libido], but at the moment it looks it is our only supported workflow for checking out and building a release version of chromium.

Cheers,
Primiano


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

Odin Hørthe Omdal

unread,
Apr 24, 2014, 7:26:04 AM4/24/14
to chromi...@chromium.org, magree...@gmail.com

On Tuesday, April 22, 2014 8:42:21 AM UTC+2, Primiano Tucci wrote:
> I'm trying to build Chromium at a specific release version using only a git checkout. 
This is essentially wrong per definition and is not supported. Probably things will change soon(ish), see the thread about migration to Git.
Sadly this question / kind of mistake comes on chromium-dev on a monthly basis. We should probably just improve the docs at this point.

Or possibly in glorious future make it possible/simple/easy to understand?  I don't know all the issues and problems that led to the creation of gclient and this DEPS system in the first place.  We've been living without it in Opera quite successfully so far (only one git tree with (some recursive) git submodules, not having/using any extra tools except git). A branch is just a git branch etc. It is all very simple and easy to understand. :)
 
Please note that "working on a release branch" is != "build a release version of chrome".
In general you should need to follow the "working on a release branch" instructions only if you are a committer needing to cherry-pick / mangle something on a release branch and for whatever reason you can't use drover. In any other case, is very unlikely that those instructions will give you anything helpful. In this specific case, for instance, this doesn't seem what you want to do here.

If you want to just build chromium as released for a given release X, the only publicly supported workflow is using SVN as follows:

That's it. Any other workflow will very likely end up with some uncompilable garbage or will just compile a lie.
The reason is that, as you figured out, the DEPS (and .DEPS.git) files in the release branch are pretty much meaningless (they are a snapshot of the DEPS at the branch point).

AFAIK there is no easy way to recreate the .DEPS.git file from a SVN release branch DEPS.
Just use SVN. I can agree that SVN is slow, tedious and [any other adjective ad libido], but at the moment it looks it is our only supported workflow for checking out and building a release version of chromium.

The question here is of course will this continue to work after the flag day?  There's talk about "every bot needs to use Git on that day". Our Chromium import scripts works by getting the release code and committing the new tree as a "Chromium update 34.0.1847.9" commit.

So you are saying that this will change, but not yet (i.e. there'll be some announcement later when development is already git-based)?  Not in this first move?

dave.chand....@gmail.com

unread,
Apr 24, 2014, 10:43:06 AM4/24/14
to chromi...@chromium.org, magree...@gmail.com

AFAIK there is no easy way to recreate the .DEPS.git file from a SVN release branch DEPS.
Just use SVN. I can agree that SVN is slow, tedious and [any other adjective ad libido], but at the moment it looks it is our only supported workflow for checking out and building a release version of chromium.

I am trying to build chromium release 35.0.1916.47 on windows.

I have followed the instructions below, with the exception being that I changed svn:// to http://, since svn:// requires some sort of authentication:

# Make sure this is in a new directory with no existing .gclient.

svn ls svn://svn.chromium.org/chrome/releases/

gclient config svn://svn.chromium.org/chrome/releases/34.0.1847.9

gclient sync --jobs 16

However I get the following error when I run gclient runhooks:


Enabled Psyco JIT.

Updating projects from gyp files...

gyp: E:\src\chromium_src\svn_src\src\third_party\WebKit\Source\build\features.gypi not found (cwd: E:\src\chromium_src\svn_src) wh

ile reading includes of E:\src\chromium_src\svn_src\src\third_party\WebKit\public\blink.gyp

gyp: E:\src\chromium_src\svn_src\src\third_party\WebKit\Source\build\features.gypi not found (cwd: E:\src\chromium_src\svn_src) wh

ile reading includes of E:\src\chromium_src\svn_src\src\third_party\WebKit\public\all.gyp

Using overrides found in C:\Users\dave\.gyp\include.gypi

Error: Command e:\src\chromium_src\svn_src\depot_tools\python276_bin\python.exe src/build/gyp_chromium returned non-zero exit stat

us 1 in E:\src\chromium_src\svn_src

Hook ''e:\src\chromium_src\svn_src\depot_tools\python276_bin\python.exe' src/build/gyp_chromium' took 19.98 secs

regards,

Dave. 
 

Primiano Tucci

unread,
Apr 25, 2014, 8:47:48 AM4/25/14
to odi...@opera.com, Chromium-dev, magree...@gmail.com, Chase Phillips
Or possibly in glorious future make it possible/simple/easy to understand?  I don't know all the issues and problems that led to the creation of gclient and this DEPS system in the first place.
DEPS was a necessity in the dark ages of SVN, in order to handle subprojects references and get, essentially, an equivalent of git submodules. Note that, at the time of writing, SVN is still the source of truth for chromium. At the moment, git is just mirroring svn for the main project and almost all the subprojects (sad face).
 
 We've been living without it in Opera quite successfully so far (only one git tree with (some recursive) git submodules, not having/using any extra tools except git). 
I think the core of the problem boils down to make changes to the projects, committing to SVN, checking out release branches (and committing to them) etc. Read-only mirroring, as in your case, is definitely easier. For instance it looks like at the moment, Rietveld is not able to deal with submodules changes. That would make reviewing rolls a bit complicated.
 
A branch is just a git branch etc. It is all very simple and easy to understand. :)
 
I agree with you that using just plain git with no extra layers (at least as regards checking out code) would be uber-nice. I am not the right person to ask though.
If you want more details there was a recent PSA and a thread entitled "Submodules workflow" which was announcing deprecation of the submodules workflow and explaining the reasons.
If you have more doubts you should just reply to that thread.
 
The question here is of course will this continue to work after the flag day?  There's talk about "every bot needs to use Git on that day". Our Chromium import scripts works by getting the release code and committing the new tree as a "Chromium update 34.0.1847.9" commit.

This is an excellent question. Chase, any clues?
 
So you are saying that this will change, but not yet (i.e. there'll be some announcement later when development is already git-based)?  Not in this first move?
 
No, I'm not the right person to say what and when will change. I know what I read from this mailing list as you do.
I'm just saying that at the moment, this is the supported way to checkout and build a release version of Chromium. That's it :)
 

Chase Phillips

unread,
Apr 25, 2014, 1:47:31 PM4/25/14
to Primiano Tucci, Michael Moss, Stefan Zager, Robert Iannucci, Aaron Gable, Ryan Tseng, Ben Henry, odi...@opera.com, Chromium-dev, magree...@gmail.com
On Fri, Apr 25, 2014 at 5:47 AM, Primiano Tucci <prim...@chromium.org> wrote:
 
The question here is of course will this continue to work after the flag day?  There's talk about "every bot needs to use Git on that day". Our Chromium import scripts works by getting the release code and committing the new tree as a "Chromium update 34.0.1847.9" commit.

This is an excellent question. Chase, any clues?
 
So you are saying that this will change, but not yet (i.e. there'll be some announcement later when development is already git-based)?  Not in this first move?
 
No, I'm not the right person to say what and when will change. I know what I read from this mailing list as you do.
I'm just saying that at the moment, this is the supported way to checkout and build a release version of Chromium. That's it :)
 

Michael (mmoss@) and others (cc'd) have been working on this and will let them comment.

Chase 

Michael Moss

unread,
Apr 25, 2014, 2:42:49 PM4/25/14
to Marshall Greenblatt, chromium-dev
Short answer is, we should probably take the 'src' entry out of the git buildspecs (the release tagged .DEPS.git). It made sense for the svn buildspecs, which were separate from the svn 'src' repository, but it obviously confuses gclient when they're not. Does method [1] work if you edit src/.DEPS.git and remove the 'src' entry?


Michael Moss

unread,
Apr 25, 2014, 2:47:00 PM4/25/14
to Marshall Greenblatt, chromium-dev
To clarify, this is the process I meant to test:

git checkout refs/tags/35.0.1916.27
# edit .DEPS.git to remove the 'src' entry
gclient sync -nohooks --jobs 16

Marshall Greenblatt

unread,
Apr 25, 2014, 3:04:16 PM4/25/14
to Michael Moss, chromium-dev
On Fri, Apr 25, 2014 at 2:47 PM, Michael Moss <mm...@chromium.org> wrote:
To clarify, this is the process I meant to test:

git checkout refs/tags/35.0.1916.27
# edit .DEPS.git to remove the 'src' entry
gclient sync -nohooks --jobs 16

This gets me here:

Error: Command git checkout --quiet 631b48a48e6c548f9fee7fa03fc17a63722886c0 returned non-zero exit status 128 in C:\cod
e\chromium_git\chromium\src\third_party\WebKit
fatal: reference is not a tree: 631b48a48e6c548f9fee7fa03fc17a63722886c0

I believe this is because 'src/third_party/WebKit' uses https://chromium.googlesource.com/chromium/blink.git which doesn't contain Blink release branches. Is there a public Blink git repo that does include the release branches?

Michael Moss

unread,
Apr 25, 2014, 3:16:12 PM4/25/14
to Marshall Greenblatt, chromium-dev
blink.git does have the release branches, under branch-heads, just like src.git. I assumed you synced using ''--with_branch_heads", since you mentioned that in a previous command, but maybe your previous checkout never got that far. Try adding that to the sync command you're using now.

Marshall Greenblatt

unread,
Apr 25, 2014, 3:44:37 PM4/25/14
to Michael Moss, chromium-dev
On Fri, Apr 25, 2014 at 3:16 PM, Michael Moss <mm...@chromium.org> wrote:
blink.git does have the release branches, under branch-heads, just like src.git. I assumed you synced using ''--with_branch_heads", since you mentioned that in a previous command, but maybe your previous checkout never got that far. Try adding that to the sync command you're using now.

OK, that worked. I guess it matters what I have checked out in src.git when running `gclient sync --with_branch_heads`. Using "--with_branch_heads" before checking out refs/tags/35.0.1916.27 didn't update the blink.git branch-heads.

Michael Moss

unread,
Apr 25, 2014, 4:17:56 PM4/25/14
to Marshall Greenblatt, chromium-dev
FWIW, it also appears to work if you set:

    "custom_deps" : {
      "src": None,
    }

in the "src" solution of the .gclient file. That's probably the best fix until the git buildspecs can be updated to remove the 'src' entries.

Marshall Greenblatt

unread,
Apr 25, 2014, 8:52:46 PM4/25/14
to Michael Moss, chromium-dev
On Fri, Apr 25, 2014 at 4:17 PM, Michael Moss <mm...@chromium.org> wrote:
FWIW, it also appears to work if you set:

    "custom_deps" : {
      "src": None,
    }

in the "src" solution of the .gclient file. That's probably the best fix until the git buildspecs can be updated to remove the 'src' entries.

Excluding 'src' has the unfortunate side effect of causing a new checkout to fail :(

So this is what I'm using now and have verified works:

1. For the initial checkout, use the following instead of `fetch chromium`:

A. Create the following .gclient file to exclude some unnecessary (and large) deps:
solutions = [{u'managed': False,u'name': u'src', u'url': u'https://chromium.googlesource.com/chromium/src.git', u'custom_deps': {u'build': None, u'build/scripts/command_wrapper/bin': None, u'build/scripts/gsd_generate_index': None, u'build/scripts/private/data/reliability': None, u'build/third_party/lighttpd': None, u'commit-queue': None, u'depot_tools': None, u'src/chrome_frame/tools/test/reference_build/chrome': None, u'src/chrome/tools/test/reference_build/chrome_linux': None, u'src/chrome/tools/test/reference_build/chrome_mac': None, u'src/chrome/tools/test/reference_build/chrome_win': None, }, u'deps_file': u'.DEPS.git', u'safesync_url': u''}]

B. Run:
gclient sync --nohooks --with_branch_heads --jobs 16

2. For each update thereafter, run:
git fetch
git checkout refs/tags/35.0.1916.27
# edit .DEPS.git to remove the 'src' entry
gclient sync --with_branch_heads --jobs 16

Out of curiosity, why does "build/scripts/private/data/reliability" pull in a while new clone of src.git? That adds a lot of download time :)

Jiang Kelvin

unread,
May 5, 2014, 1:08:37 AM5/5/14
to magree...@gmail.com, Michael Moss, chromium-dev
I have another question. Why there are difference between
and
and which source should I pick?


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Primiano Tucci

unread,
May 5, 2014, 4:43:14 AM5/5/14
to leiy...@gmail.com, magree...@gmail.com, Michael Moss, chromium-dev
Let's try list them all. 

This is NOT what you think it might be. This is the snapshot of DEPS at the branch point, i.e. at the time when we decided to fork the release branch.
In this specific case (i.e. 35.0.1916) the BP was somewhere around r260203 in trunk. In fact you can see that the content of that DEPS is pretty much identical to http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?revision=260203&pathrev=260203, which is on trunk
Ditto for .DEPS.git in the SVN release branch.

Corollary: DEPS/.DEPS.git in a SVN release branch are misleading.
The content of DEPS / .DEPS.git in a SVN rel. branch is misleading. They reflect the DEPS at the branch point. Those DEPS are not even guaranteed to compile agains the code of the main project in the release branch. The main project code might have been diverged, merge after merge, on the release branch (while the DEPS stay frozen and reflect the B.P.).

2) Where are true DEPS for a release branch in SVN?

Corollary: the official way of checking out a Chrome release 
The officially supported (and documented) way of checking out a meaningful and consistent release version of chrome is, in fact:
gclient config http://src.chromium.org/chrome/releases/35.0.1916.49  (replace s|http://src|svn://svn| for committers)


What about Git?
I have to admit that the overall git situations looks still a bit mysterious to me. I can never work out what is there because it is officially meant to be there, what is there because of an experiment/not-so-supported workflow or what is there just by chance.
Just looking at the current situation, and by no means implying that this is supported or going to be supported, this is how it looks to me.

3) DEPS in a Git release tag:
This looks actually "true" and seems === to the true SVN DEPS [2]
However I find hard to imagine how to use this DEPS (hence SVN-related) file from a git checkout. I bet that gclient would be pretty confused by such a combination.

4) .DEPS.git in a Git release tag:
This seems to be the correct Git translation of the truthful DEPS [2].
According to this thread, this seems to be usable for checking out a consistent release of Chrome via Git according, using the controverse workflow described by the previous mails in this thread (i.e. checkout the tag, remove src from custom_deps, gclient sync).
Unless I'm missing something here, this workflow is currently undocumented hence unsupported (somebody please correct me AND our instructions if I'm wrong)

Jiang Kelvin

unread,
May 5, 2014, 5:03:40 AM5/5/14
to Primiano Tucci, magree...@gmail.com, Michael Moss, chromium-dev
It's very clear! Thanks very much.

Stefan Zager

unread,
May 5, 2014, 11:46:08 AM5/5/14
to prim...@chromium.org, leiy...@gmail.com, magree...@gmail.com, Michael Moss, chromium-dev
On Mon, May 5, 2014 at 1:43 AM, Primiano Tucci <prim...@chromium.org> wrote:

3) DEPS in a Git release tag:
This looks actually "true" and seems === to the true SVN DEPS [2]
However I find hard to imagine how to use this DEPS (hence SVN-related) file from a git checkout. I bet that gclient would be pretty confused by such a combination.

4) .DEPS.git in a Git release tag:
This seems to be the correct Git translation of the truthful DEPS [2].
According to this thread, this seems to be usable for checking out a consistent release of Chrome via Git according, using the controverse workflow described by the previous mails in this thread (i.e. checkout the tag, remove src from custom_deps, gclient sync).
Unless I'm missing something here, this workflow is currently undocumented hence unsupported (somebody please correct me AND our instructions if I'm wrong)


I expect mmoss@ to chime in at some point, since he did all the work on this, but you are basically correct.  As part of the final git migration process, .DEPS.git will disappear from trunk, and its contents will be moved to DEPS.  There will be no SVN-style DEPS in future release branches.

We will also no longer maintain buildspec files on a separate path in the repository (e.g., http://src.chromium.org/chrome/releases/35.0.1916.49/DEPS).  The DEPS file at the release branch/tag will be the correct set of dependencies for the release build.

The fact that there's still a 'src' entry in the .DEPS.git of historical release builds is just a historical artifact.  Going forward, DEPS on a release branch will not have a 'src' entry.

Stefan

Primiano Tucci

unread,
May 6, 2014, 5:30:42 AM5/6/14
to Stefan Zager, Jiang Kelvin, magree...@gmail.com, Michael Moss, chromium-dev
> .DEPS.git will disappear from trunk, and its contents will be moved to DEPS.  

Just out of curiosity:  is there a reason for the rename vs. keep calling it .DEPS.git? I just fear it will be a bit confusing for people / tools.
I am thinking to stuff like bisecting bugs/regressions across the switch point. Will gclient be able to deal with that? (that = the fact that in older versions the deps are in .DEPS.git and later they will be in DEPS)?

Michael Moss

unread,
May 21, 2014, 5:54:29 PM5/21/14
to chromi...@chromium.org, Marshall Greenblatt
Quick follow-up. As of yesterday, new release tags have the 'src' entry removed from DEPS and .DEPS.git. For example:


so something like:
  git checkout refs/tags/37.0.2007.0
  gclient sync

should work now. I still need to update all previous releases, so it still won't work for things like 35.0.1916.27 mentioned earlier in this thread.

Michael

Odin Hørthe Omdal

unread,
May 22, 2014, 8:04:22 AM5/22/14
to chromi...@chromium.org
On Wed, May 21, 2014, at 23:54, Michael Moss wrote:
> Quick follow-up. As of yesterday, new release tags have the 'src' entry
> removed from DEPS and .DEPS.git. For example:
>
> https://chromium.googlesource.com/chromium/src/+/37.0.2007.0/.DEPS.git
>
> so something like:
> git checkout refs/tags/37.0.2007.0
> gclient sync
>
> should work now. I still need to update all previous releases, so it
> still won't work for things like 35.0.1916.27 mentioned earlier
> in this thread.

That's awesome. :)


I notice that 35.0.1916.114 still has the 'src' in there[0]. Will the
next stable update after this one also have the 'src' in there? Or is
this an infrastructure change that will make every DEPS.git file created
after this point in time be "good"?

If this is tied-in with versions; from what version was this implemented
(or a more direct question would be; what release will be the last one
that should be checked out using SVN?).


(It'll be a joy moving away from SVN even though it's mostly used just
to get the files which we then check into our upstream tracking branches
in our chromium/src Git repository :) )


0.
https://chromium.googlesource.com/chromium/src/+/35.0.1916.114/.DEPS.git

--
Odin Hørthe Omdal
odi...@opera.com

Michael Moss

unread,
May 22, 2014, 10:58:47 AM5/22/14
to Odin Hørthe Omdal, chromium-dev
On Thu, May 22, 2014 at 5:04 AM, Odin Hørthe Omdal <odi...@opera.com> wrote:
On Wed, May 21, 2014, at 23:54, Michael Moss wrote:
> Quick follow-up. As of yesterday, new release tags have the 'src' entry
> removed from DEPS and .DEPS.git. For example:
>
> https://chromium.googlesource.com/chromium/src/+/37.0.2007.0/.DEPS.git
>
> so something like:
>   git checkout refs/tags/37.0.2007.0
>   gclient sync
>
> should work now. I still need to update all previous releases, so it
> still won't work for things like 35.0.1916.27 mentioned earlier
> in this thread.

That's awesome. :)


I notice that 35.0.1916.114 still has the 'src' in there[0]. Will the
next stable update after this one also have the 'src' in there? Or is
this an infrastructure change that will make every DEPS.git file created
after this point in time be "good"?

Only DEPS added since Tues have the fix. The next stable release should have it, whenever that happens.
 

If this is tied-in with versions; from what version was this implemented
(or a more direct question would be; what release will be the last one
that should be checked out using SVN?).

The fix will eventually be applied to all DEPS/.DEPS.git, but I don't have an ETA yet. It's on the blocking list for fully migrating to src.git.
 


(It'll be a joy moving away from SVN even though it's mostly used just
to get the files which we then check into our upstream tracking branches
in our chromium/src Git repository :) )


0.
https://chromium.googlesource.com/chromium/src/+/35.0.1916.114/.DEPS.git

--
  Odin Hørthe Omdal
  odi...@opera.com
--
--
Chromium Developers mailing list: chromi...@chromium.org
Reply all
Reply to author
Forward
0 new messages