Summary:
I'm trying to push D59198 but it seems that `git-llvm push` can't handle the fact
that I add a new directory in the patch:
```
> git llvm push -n
Pushing 1 commit:
e7c0a9bd136 Correctly look up declarations in inline namespaces
Traceback (most recent call last):
File "llvm/utils/git-svn//git-llvm", line 431, in <module>
args.func(args)
File "llvm/utils/git-svn//git-llvm", line 385, in cmd_push
clean_svn(svn_root)
File "llvm/utils/git-svn//git-llvm", line 201, in clean_svn
os.remove(os.path.join(svn_repo, filename))
IsADirectoryError: [Errno 21] Is a directory: '.git/llvm-upstream-svn/lldb/trunk/packages/Python/lldbsuite/test/expression_command/inline-namespace'
```
This patch just uses shutil to delete the directory instead of trying to use `os.remove`
which only works for files.
Reviewers: mehdi_amini, jlebar
Reviewed By: jlebar
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59236
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355896 91177308-0d34-0410-b5e6-96231b3b80d8
The --force-interactive option was introduced in SVN 1.8, and trying to
pass it to older SVN clients causes an error; CentOS 7 includes SVN 1.7,
for example, so this makes `git llvm` not usable out of the box. Older
clients would be interactive by default anyway [1], so just don't pass
the option if it's not supported.
An alternative would be to check the version instead of checking the
help text, but I think directly detecting the presence of the option is
more direct.
[1] http://svn.apache.org/viewvc?view=revision&revision=1424037
Differential Revision: https://reviews.llvm.org/D59161
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355782 91177308-0d34-0410-b5e6-96231b3b80d8
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
"svn update --depth=..." is, annoyingly, not a specification of the
desired depth, but rather a _limit_ added on top of the "sticky" depth
in the working-directory. However, if the directory doesn't exist yet,
then it sets the sticky depth of the new directory entries.
Unfortunately, the svn command-line has no way of expanding the depth
of a directory from "empty" to "files", without also removing any
already-expanded subdirectories. The way you're supposed to increase
the depth of an existing directory is via --set-depth, but
--set-depth=files will also remove any subdirs which were already
requested.
This change avoids getting into the state of ever needing to increase
the depth of an existing directory from "empty" to "files" in the
first place, by:
1. Use svn update --depth=files, not --depth=immediates.
The latter has the effect of checking out the subdirectories and
marking them as depth=empty. The former excludes sub-directories from
the list of entries, which avoids the problem.
2. Explicitly populate missing parent directories.
Using --parents seemed nice and easy, but it marks the parent dirs as
depth=empty. Instead, check out parents explicitly if they're missing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347883 91177308-0d34-0410-b5e6-96231b3b80d8
On python3, use bytes for reading and applying the patch file, rather
than str. This fixes encoding issues when applying patches with
python3.X (reported by zturner).
Also, simplify and speed up "svn update" via svn's "--parents"
argument, instead of manually computing and supplying the list of
parent directories to update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347766 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes three issues.
The first is that we didn't consider files which are explicitly
set to eolstyle CRLF in the repo, and there are a handful of
these.
Second is that dos2unix doesn't have a -q option in GnuWin32,
so this codepath wasn't working properly.
Finally with newer versions of Python (or newer versions of Git,
or some combination of the two) patches can't be applied when
we treat stdin as text, because Python silently undoes all the
work we did to convert the newlines to LF using dos2unix by
using universal_newlines=True and then converting them *back*
to CRLF. So we need to add a way to force stdin to be treated
as binary, and use it when LF-newlines are required.
Differential Revision: https://reviews.llvm.org/D51444
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344095 91177308-0d34-0410-b5e6-96231b3b80d8
The error message that git-llvm script prints out when svn is missing
is very cryptic. I spent a fair amount of time to find what was wrong
with my environment. It looks like many newcomers also exprienced a
hard time to submit their first patches due to this error.
This patch adds a more user-friendly error message.
Differential Revision: https://reviews.llvm.org/D33458
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303696 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
`git apply` on Windows doesn't work for files that SVN checks out as
CRLF. There is no way to force SVN to check everything out with Unix
line endings on Windows. Files with svn:eol-style=native will always
come out with CRLF, breaking `git apply`, which wants Unix line endings.
My workaround is to list all files with this property set in the change,
and run `dos2unix` on them. SVN doesn't commit a massive line ending
change because the svn:eol-style property indicates that these are text
files.
Tested on r301245.
Reviewers: zturner, jlebar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301262 91177308-0d34-0410-b5e6-96231b3b80d8
When svn does not know the password and it has to prompt, it needs to query.
However it won't when invoked from the Python script and instead fails with:
svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
Differential Revision: https://reviews.llvm.org/D27274
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288266 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new script in llvm/utils/git-svn/. When present in the $PATH,
it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Differential Revision: https://reviews.llvm.org/D26334
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286138 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some changes are made to cmake, especially the addition of a new
LLVM_ENABLE_PROJECTS option that makes the build system aware of
the monorepo directory structure.
Also a new script is added in llvm/utils/git-svn/. When present in
the $PATH, it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Reviewers: jlebar
Subscribers: mgorny, modocache, llvm-commits
Differential Revision: https://reviews.llvm.org/D26334
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286123 91177308-0d34-0410-b5e6-96231b3b80d8
