Make repository select the deepest repository in the directory tree
Review Request #9620 — Created Feb. 11, 2018 and submitted
Without the presence of a .reviewboardrc file which defines
REPOSITORY_TYPE, RBTools will try to auto-detect the repository type by running
various commands like "svn info", "hg root", etc. This will run through each
repository type until one is found that works.Unfortunately, if people have nested repositories, this means
RBTools can select the wrong one. For example, some people may have
/home/user/ as a git directory, and /home/user/src/project/ is a subversion
checkout, running "rbt" within their "project" directory may detect it as git
instead of svn.This change auto-detects all repository types, and then selects the
deepest one. In the case of multiple matching repositories, we output a
warning suggesting that people define REPOSITORY_TYPE in .reviewboardrc in
order to speed up detection.
- Tested combinations of nested svn, git, hg repos.
- All unit tests pass.
Description | From | Last Updated |
---|---|---|
Can you wrap your description to 70 columns? |
david | |
E265 block comment should start with '# ' |
reviewbot | |
E501 line too long (98 > 79 characters) |
reviewbot | |
E501 line too long (83 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (95 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E265 block comment should start with '# ' |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E265 block comment should start with '# ' |
reviewbot | |
E501 line too long (110 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (82 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (95 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E265 block comment should start with '# ' |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E265 block comment should start with '# ' |
reviewbot | |
E501 line too long (110 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E501 line too long (82 > 79 characters) |
reviewbot | |
E266 too many leading '#' for block comment |
reviewbot | |
E261 at least two spaces before inline comment |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E116 unexpected indentation (comment) |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E116 unexpected indentation (comment) |
reviewbot | |
E126 continuation line over-indented for hanging indent |
reviewbot | |
E261 at least two spaces before inline comment |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E116 unexpected indentation (comment) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E251 unexpected spaces around keyword / parameter equals |
reviewbot | |
E501 line too long (86 > 79 characters) |
reviewbot | |
E251 unexpected spaces around keyword / parameter equals |
reviewbot | |
E261 at least two spaces before inline comment |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E116 unexpected indentation (comment) |
reviewbot | |
E251 unexpected spaces around keyword / parameter equals |
reviewbot | |
E261 at least two spaces before inline comment |
reviewbot | |
E114 indentation is not a multiple of four (comment) |
reviewbot | |
E116 unexpected indentation (comment) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
F841 local variable 'local_root' is assigned to but never used |
reviewbot | |
W293 blank line contains whitespace |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E303 too many blank lines (2) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
E501 line too long (80 > 79 characters) |
reviewbot | |
These should be in alphabetical order. |
david | |
Should be "self.path". Even though it's starting a sentence, self refers to a symbol. |
david | |
There's an extra space at the beginning of this comment line. |
david | |
Add a blank line between these (we like to have a bit of space before and after blocks) |
david | |
Add a blank line between these. |
david | |
Hmmm. We should probably just make sure that get_repository_info doesn't change things. Needing a special case here is ugly. |
david | |
Add a blank line between these. |
david | |
We generally prefer to have the joining space at the end of the previous line instead of the beginning of … |
david | |
Blank line between these. |
david | |
Blank line between these. |
david | |
Blank line between these. |
david | |
Also not necessary if we fix up GitClient. |
david | |
This looks like leftover debug output. Can we get rid of it? |
david | |
More fallout from GitClient being dumb. |
david | |
And here. |
david | |
Blank line between these. |
david | |
I think this function might be a bit too long. Might be a good idea to break it up, for … |
rpolyano | |
Too many blank lines here now. |
david | |
Not enough blank lines here now. |
david | |
Blank line here. |
david | |
Would it make sense to move all of these Regexes out into one place and a) have them organized by … |
rpolyano | |
Blank line here. |
david | |
Blank line here. |
david | |
Blank line here. |
david | |
This should fit all on one line. |
david | |
From my understanding, the idea here is to find the deepest repo in terms of directory depth right? Using the … |
jshephard | |
This would wrap more nicely as: if (repo.local_root and len(os.path.normpath(repo.local_root)) > deepest_repo): |
david | |
Does the >>>>>>>> mean anything or is it a part of the reviewboard UI? |
JT jtrang | |
Oh I see! That makes a lot more sense. Thank you! |
JT jtrang | |
Please use single quotes instead of double, and add a blank line above this. |
david | |
Same comment as above. I'm not sure if the chevrons are appearing as part of the UI or not. |
JT jtrang |
- Change Summary:
-
Check if git changes the CWD, roll back until other clients find their repos, and then find deepest repo. Cannot stop gitClient from changing CWD as that ensures diffs on server are not messed up. Check if git changes the CWD, roll back until other clients find their repos, and then find deepest. Cannot stop gitClient from changing CWD as that ensures diffs on server are not messed up.
Checks run (1 failed, 1 succeeded)
flake8
- Description:
-
Without the presence of a .reviewboardrc file which defines REPOSITORY_TYPE, RBTools will try to auto-detect the repository type by running various commands like "svn info", "hg root", etc. This will run through each repository type until one is found that works.
~ Unfortunately, if people have nested repositories, this means RBTools can select the wrong one. For example, some people may have /home/user/ as a git directory, and /home/user/src/project/ is a subversion checkout, running "rbt" within their "project" directory may detect it as git instead of svn. We'd like to auto-detect all repository types, and then select the deepest one.
~ Unfortunately, if people have nested repositories, this means RBTools can select the wrong one. For example, some people may have /home/user/ as a git directory, and /home/user/src/project/ is a subversion checkout, running "rbt" within their "project" directory may detect it as git instead of svn. This change auto-detects all repository types, and then selects the deepest one.
~ In the case of multiple matching repositories, we may want to output a warning suggesting that people define REPOSITORY_TYPE in .reviewboardrc in order to speed up detection.
~ In the case of multiple matching repositories, we output a warning suggesting that people define REPOSITORY_TYPE in .reviewboardrc in order to speed up detection.
- Commit:
-
1b9c14f1524fb0f4d12834f8fdfef956bddc54e133dde16cf2afda0204792f8e01a38f75631e8470
Checks run (1 failed, 1 succeeded)
flake8
- Change Summary:
-
Rebased the branch on release-0.7.x to avoid rbt post error after new changes on master were pulled.
- Testing Done:
-
~ - Tested combinations of nested svn and git repos, both were unaffected by this issue.
~ - Tested combinations of nested svn, git, hg repos
- - Tested mercurial repo nested in a git repo.
- Branch:
-
deepestreporelease-0.7.x
- Commit:
-
33dde16cf2afda0204792f8e01a38f75631e84706996a3346f42ac105c9025ef413ea7646f9a7e71
- Testing Done:
-
~ - Tested combinations of nested svn, git, hg repos
~ - Tested combinations of nested svn, git, hg repos.
- Summary:
-
[WIP] Make repository select the deepest repository in the directory treeMake repository select the deepest repository in the directory tree
- Testing Done:
-
- Tested combinations of nested svn, git, hg repos.
+ - All unit tests pass.
- Change Summary:
-
Fixed spacing issues
- Commit:
-
6996a3346f42ac105c9025ef413ea7646f9a7e71a2d2924edc36a72f8bad3a4c2d01dfe7fd858574
Checks run (2 succeeded)
-
-
I think this function might be a bit too long. Might be a good idea to break it up, for example some of the if/branches can be separate functions.
-
Would it make sense to move all of these Regexes out into one place and a) have them organized by version ranges (e.x. git may change these in some version) and b) compile them
- Description:
-
~ Without the presence of a .reviewboardrc file which defines REPOSITORY_TYPE, RBTools will try to auto-detect the repository type by running various commands like "svn info", "hg root", etc. This will run through each repository type until one is found that works.
~ Without the presence of a .reviewboardrc file which defines
+ REPOSITORY_TYPE, RBTools will try to auto-detect the repository type by running + various commands like "svn info", "hg root", etc. This will run through each + repository type until one is found that works. ~ Unfortunately, if people have nested repositories, this means RBTools can select the wrong one. For example, some people may have /home/user/ as a git directory, and /home/user/src/project/ is a subversion checkout, running "rbt" within their "project" directory may detect it as git instead of svn. This change auto-detects all repository types, and then selects the deepest one.
~ Unfortunately, if people have nested repositories, this means
+ RBTools can select the wrong one. For example, some people may have + /home/user/ as a git directory, and /home/user/src/project/ is a subversion + checkout, running "rbt" within their "project" directory may detect it as git + instead of svn. ~ In the case of multiple matching repositories, we output a warning suggesting that people define REPOSITORY_TYPE in .reviewboardrc in order to speed up detection.
~ This change auto-detects all repository types, and then selects the
+ deepest one. In the case of multiple matching repositories, we output a + warning suggesting that people define REPOSITORY_TYPE in .reviewboardrc in + order to speed up detection. - Commit:
-
a2d2924edc36a72f8bad3a4c2d01dfe7fd8585747a16851cc4b4cc37183d14a7e882dbdbfa74ac16
Checks run (2 succeeded)
-
-
From my understanding, the idea here is to find the deepest repo in terms of directory depth right? Using the length of the path to determine this might result in selecting a repo that is in a directory with a large name over another repo that is deeper.
I'm not sure if this is an issue here though, as your description makes it sound like you're just looking at parent directories of the user's current working directory. In that case this is a non-issue.