This changes the shebangs for the update_checkout executable files to
specifically call Python 3. The code is already compatible and
functional with python3, so this removes any implied backward
compatibility, and removes any ambiguity based on the user's current
environment, especially since some systems, like macOS, still link
'python' to Python 2.
This also removes the now unnecessary 'from __future__' imports.
Hacking sys.modules here was added unconditionally to fix an import problem on
Windows (with Python 2.7???).
This script works fine on Python 2.7 on macOS either with or without this hack.
This script breaks badly on Python 3.8 on macOS with this hack, so I've disabled
it here for all Python 3.
* Python3 compatibility for Benchmarks
Three issues addressed here:
1. Dependency on dictionary iteration order
CharacterProperties.swift.gyb iterated a dictionary to produce its output.
Changed this to a list of tuples to ensure the order is predictable.
2. Python3 `map` returns an iterator, not a list
Changed a bunch of `map` calls to `list(map(...))` to ensure the result is a list
3. Python3 `int()` expects a string, won't accept a list of characters
Added a concatenation step that is effectively a no-op on Python2
* Make update-checkout work with Python3
Python3 doesn't like to pickle local functions, so make the multiprocessing
initialization function be global.
Python3 multiprocessing also seems to require conditional execution of the
top-level code. TBH, I'm not entirely sure why Python 2 didn't need this.
* Adjust whitespace per python-lint
Reworks the update_all_repositories() and update_single_repository()
functions to benefit from more per-repo parallelism.
* Branch-scheme search loop is relocated from update_repository_to_scheme()
to update_all_repositories().
* Functions update_repository_to_tag() and update_repository_to_scheme()
are removed.
* Per-repo work of these functions is shifted to update_single_repository().
* Repeated work (repeated pushd's, etc.) has been eliminated.
* As much work as possible is performed within update_single_repository()'s
outer try clause to catch more errors.
* Arguments passed to update_single_repository() have been changed
appropriately.
* New helper functions confirm_tag_in_repo() and get_branch_for_repo() added
to keep update_single_repository()'s length under control.
* Unnecessary setting of the cross_repo flag by the --tag argument has been
removed, so repos which lack the tag are now properly rebased when updated.
* utils/update-checkout: Fix for mishandling detached HEAD in SR-3854
In update_single_repository, before doing the rebase step, check whether
the current HEAD is a "detached HEAD", normally the result of checking
out a tag by previously invoking update-checkout with the --tag option.
If HEAD is a detached HEAD, skip the rebase (and print an explanatory
message), because rebasing would do the wrong thing and make a mess.
* utils/update-checkout: more robust error handling for SR-3854 fix
We now examine the exception raised by the "git symbolic-ref -q HEAD"
command to check whether the exception was indeed due to a detached HEAD.
If there was an actual error in the command, we re-raise the exception
so that it can be handled like errors from other commands.
utils/update-checkout: Add a call to ``git rebase --abort`` when using the ``--clean`` option.
Calling ``git fetch`` updates .git/FETCH_HEAD and marks all branches
besides the currently checked out branch as not-for-merge. So tot
ensure that the branch we want to merge is available for merging, we
must do a checkout of that branch before updating the FETCH_HEAD file.
We also must ensure that we have fetched before optionally resetting to remote.
Fixes https://bugs.swift.org/browse/SR-3800.
The --clean option is meant to restore your repository to a pristine
condition, but there are cases where you can ``reset --hard`` and still be
in the middle of a rebase. This is annoying across 10+ repositories, so
if the user wants to --clean, then abort all rebases in progress.
I think update-checkout is growing to the point, we should probably rename it to
something like repo-tool.
The output of this command looks as follows:
clang 973bd1a Merge remote-tracking branch 'origin/swift-3.1-branch' into stable
cmark 5af77f3 Merge pull request #95 from kainjow/master
compiler-rt 1f24bd0 Merge remote-tracking branch 'origin/swift-3.1-branch' into stable
llbuild c324ee3 Merge pull request #35 from tinysun212/pr-cygwin-1
lldb f6a5830 Adjust LLDB for changes to the layout of _SwiftTypePreservingNSNumber
llvm 52482d0 Merge remote-tracking branch 'origin/swift-3.1-branch' into stable
swift 45f3d2a [update-checkout] Add a small tool to dump hashes for all of the checkout repos.
swift-corelibs-foundation cc5985e Loopback tests for URLSession (#613)
swift-corelibs-libdispatch ba7802e Merge pull request #178 from dgrove-oss/depend-on-swiftc
swift-corelibs-xctest 51b419d Merge pull request #174 from modocache/sr-1901-remove-workarounds
swift-integration-tests c95c832 Merge pull request #12 from abertelrud/fix-swift-package-init-lib-test
swift-xcode-playground-support 4b40c34 Merge pull request #10 from apple/stdlib-unittest-expect-nil
swiftpm 65403f5 [ConventionTests] Collect all the diagnostics from PackageBuilder
When building Swift from a non-clean checkout, the `git reset` that
occurs on subprojects that include submodules may fail if the submodule
is deemed to have been changed (for example, by running the autoconf
scripts).
When cleaning the projects, ensure that `git submodule` is used to clean
submodules and reset them to their original state as well, so that the
project can be reset successfully.
Issue: SR-2524
In order to not break the bots, I kept on accepting branch to specify the branch
scheme that defines the branches used for each repo. This now allows us to
accept both arguments to specify the branch scheme. Once the bots have migrated,
I will remove support for specifying the branch scheme via --branch.
We want to allow for people to use update-checkout to just update branches even
in the case where they are not using a scheme (for instance if they have a side
branch).
This means though that one can still clone and get all of the appropriate
repos/branches.
The only unfortunate thing about this change is that when cloning, already
cloned repositories that already are setup to a branch will have their branch
changed.
It would be good at some point to separate updating from cloning. It would make
update-checkout much cleaner.
I was trying to get this right a bit ago, but I remained unhappy with the
result. This at least makes it clear when reading the config file that
config['repos'].keys() serves in the code as the "source" of the names of
repositories.
update-checkout as a script has two different concepts associated with the term
'branch':
1. A "real" git branch.
2. A dictionary of names mapped to lists of (repo, git branch) pairs.
The second concept is used to specify on the command line a "palette" of
branches in all of the repositories associated with things like "master",
"master-next", and the preview branches. This is far more than a "branch". This
commit gives a unique name, "scheme" to that concept.
Keep in mind that even though the internals have changed, the outside interface
(i.e. --branch) is still the same.
That will change at a later time since I would like to change the interface
slightly which may require bots to be updated.
