tree 1cff2670aa751eaf4ea62d15d16c64ebbd33f6ea
parent a3a1366cbfccc37c3960be2b85aec3a5b6164d73
author Todd Wang <toddw@google.com> 1452043156 -0800
committer Todd Wang <toddw@google.com> 1452043835 -0800

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