commit | 7d28cfbd8c19b9db610d1ae6338d2305c21eed28 | [log] [tgz] |
---|---|---|
author | Todd Wang <toddw@google.com> | Tue Jan 05 17:19:16 2016 -0800 |
committer | Todd Wang <toddw@google.com> | Tue Jan 05 17:30:35 2016 -0800 |
tree | 1cff2670aa751eaf4ea62d15d16c64ebbd33f6ea | |
parent | a3a1366cbfccc37c3960be2b85aec3a5b6164d73 [diff] |
jiri: Fix upgrade and update for new-style manifests The old-style manifests are required to live under JIRI_ROOT/.manifest/v2, and use the <import name="foo"/> style. The new-style manifests live where the remote import specifies, and use <import/> for remote imports, and <fileimport/> for file imports. I've already pushed new-style manifests under the top-level manifest repo directory, changing all old-style name imports to new-style file imports. This CL changes the upgrade logic to write a .jiri_manifest that points to these new-style manifests. At some point we'll remove the old-style manifests, but in the interim we'll have both, to allow a gradual transition. Also fixed a bug in the "jiri update" logic. The buggy logic wrote the update_history snapshot *before* doing the update. But in order to write a snapshot, the current manifest must be read to capture the tools, hosts and hooks, since those aren't available by scanning the filesystem. The old logic is buggy because the user may have changed which manifest(s) to use, thus the tools, hosts and hooks would be for the new manifest(s), not the original one. This bug was exposed when using new-style manifests, since after "jiri upgrade v23", we'd try to run "jiri update", which would fail because the new manifest repo wasn't cloned yet. The fix is simple - we just capture the update_history snapshot *after* doing an update, rather than before. This is a better match for the intention of update_history anyways; it represents the last-known-good snapshot. In theory we could probably change the update_history snapshot logic to just write out the in-memory manifest that we've collected by performing the update. We can consider that change in subsequent cleanup. Change-Id: I601bb70c4c13c2d770dae8e06b7be2d092271aa2
“Jiri integrates repositories intelligently”
This repository implements the Jiri repository management tool.
For documentation, see http://godoc.org/v.io/jiri