(tomcat) branch 9.0.x updated: Allow users to add local scripts that will not be tracked by git
This is an automated email from the ASF dual-hosted git repository. isapir pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new 3dd2328edb Allow users to add local scripts that will not be tracked by git 3dd2328edb is described below commit 3dd2328edbbfe42eacc7f9160c594d305e87f5ac Author: Igal Sapir AuthorDate: Fri Jun 14 12:11:29 2024 -0700 Allow users to add local scripts that will not be tracked by git --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 41cd573f4f..d2f1ac409f 100644 --- a/.gitignore +++ b/.gitignore @@ -29,6 +29,7 @@ mvn.properties .externalToolBuilders .fbprefs .idea +.local .project .sdkmanrc .settings - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Allow users to add local scripts that will not be tracked by git
This is an automated email from the ASF dual-hosted git repository. isapir pushed a commit to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.1.x by this push: new 08d00a4825 Allow users to add local scripts that will not be tracked by git 08d00a4825 is described below commit 08d00a4825f7bbf5c2af437f13c31006c47e362a Author: Igal Sapir AuthorDate: Fri Jun 14 12:04:23 2024 -0700 Allow users to add local scripts that will not be tracked by git --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 41cd573f4f..d2f1ac409f 100644 --- a/.gitignore +++ b/.gitignore @@ -29,6 +29,7 @@ mvn.properties .externalToolBuilders .fbprefs .idea +.local .project .sdkmanrc .settings - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Allow users to add local scripts that will not be tracked by git
This is an automated email from the ASF dual-hosted git repository. isapir pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/main by this push: new 2b34da89e1 Allow users to add local scripts that will not be tracked by git 2b34da89e1 is described below commit 2b34da89e1226f949e948ec7501eac6f861681e4 Author: Igal Sapir AuthorDate: Fri Jun 14 11:51:24 2024 -0700 Allow users to add local scripts that will not be tracked by git --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 3e0daf152d..3993b03abf 100644 --- a/.gitignore +++ b/.gitignore @@ -29,6 +29,7 @@ mvn.properties .externalToolBuilders .fbprefs .idea +.local .pmd .project .sdkmanrc - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 01/02: Set git branch correctly.
This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit a6c9c0f3157c04326794953062a63de1d8777331 Author: Christopher Schultz AuthorDate: Fri Feb 2 14:47:08 2024 -0500 Set git branch correctly. --- build.properties.default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.properties.default b/build.properties.default index d3df06b9c7..1038a90f62 100644 --- a/build.properties.default +++ b/build.properties.default @@ -45,7 +45,7 @@ compile.debug=true compile.deprecation=false # - Documentation properties - -git.branch=main +git.branch=10.1.x # - Code quality tools # Note enabling validation uses Checkstyle which is LGPL licensed - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] 01/02: git apply requires a blank line at the end of the file
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git commit 89df072e7d4e7bd32440683b6971d20f63fe289d Author: Mark Thomas AuthorDate: Wed Sep 27 14:19:25 2023 +0100 git apply requires a blank line at the end of the file --- native/srclib/openssl/openssl-msvcrt-3.0.x.patch | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/native/srclib/openssl/openssl-msvcrt-3.0.x.patch b/native/srclib/openssl/openssl-msvcrt-3.0.x.patch index cb2d5a4ae..59ca38eca 100644 --- a/native/srclib/openssl/openssl-msvcrt-3.0.x.patch +++ b/native/srclib/openssl/openssl-msvcrt-3.0.x.patch @@ -83,4 +83,5 @@ index d073d732da..8a96f9a151 100644 +#include "e_os.h" #include "../testutil.h" #include - #include \ No newline at end of file + #include + \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] branch main updated: Fix git command in comment
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/main by this push:
new ad9b4a3fb Fix git command in comment
ad9b4a3fb is described below
commit ad9b4a3fb5c9d996751dd47d8c33aec51e50de44
Author: Mark Thomas
AuthorDate: Mon Jun 6 17:22:03 2022 +0100
Fix git command in comment
---
jnirelease.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/jnirelease.sh b/jnirelease.sh
index bcaefe33e..c71403d57 100755
--- a/jnirelease.sh
+++ b/jnirelease.sh
@@ -176,7 +176,7 @@ if [ $diffcount -ne 0 ]; then
echo " $TCJAVA_GITBASE"
echo " Either correct now by running"
echo " 'git rm -rf java/org/apache/tomcat/jni'"
-echo " 'git read-tree --prefix=java/org/apache/tomcat/jni/ -u
main:java/org/apache/tomcat/jni'"
+echo " 'git read-tree --prefix=java/org/apache/tomcat/jni/ -u
tcjava/main:java/org/apache/tomcat/jni'"
echo " 'git commit'"
echo " or run this script with -f (force)"
if [ "X$JKJNIFORCE" = "X1" ]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Update building page. Java 11 & svn -> git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new bb18cb686b Update building page. Java 11 & svn -> git
bb18cb686b is described below
commit bb18cb686b3715e52adcfa4fc4916d711c8f98df
Author: Mark Thomas
AuthorDate: Mon May 16 18:49:29 2022 +0100
Update building page. Java 11 & svn -> git
---
webapps/docs/building.xml | 18 +-
webapps/docs/changelog.xml | 9 +
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/webapps/docs/building.xml b/webapps/docs/building.xml
index b1302ec4b2..1487a814cb 100644
--- a/webapps/docs/building.xml
+++ b/webapps/docs/building.xml
@@ -43,12 +43,12 @@ The following is a quick step by step guide.
-
+
-Building Apache Tomcat requires a JDK (version 7) to be installed. You can
download one from
-http://www.oracle.com/technetwork/java/javase/downloads/index.html;>http://www.oracle.com/technetwork/java/javase/downloads/index.html
-http://openjdk.java.net/install/index.html;>http://openjdk.java.net/install/index.html
+Building Apache Tomcat requires a JDK (version 11) or later to be installed.
You
+can download one from
+https://adoptium.net/temurin/releases;>https://adoptium.net/temurin/releases
or another JDK vendor.
@@ -83,11 +83,11 @@ available, which will be used to actually perform the build.
-
+
- Tomcat SVN repository URL:
- https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/;>https://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/
+ Tomcat Git repository URL:
+ https://github.com/apache/tomcat;>https://github.com/apache/tomcat
Tomcat source packages:
@@ -95,8 +95,8 @@ available, which will be used to actually perform the build.
- Checkout the source using SVN, selecting a tag for released version or
- trunk for the current development code, or download and unpack a
+ Clone the source repository using Git, selecting a tag for released version
or
+ 8.5.x for the current development code, or download and unpack a
source package. For the remainder of this guide, the symbolic name
${tomcat.source} is used to refer to the
location where the source has been placed.
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index e614d12a46..2d5e860065 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+66064: Update the building page in the documentation web
+application to reflect changes in required Java version and source
+repository. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Update building page. Java 11 & svn -> git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new e74a357776 Update building page. Java 11 & svn -> git
e74a357776 is described below
commit e74a3577762801f20fb0a339dd6a16fef1fa878e
Author: Mark Thomas
AuthorDate: Mon May 16 18:49:29 2022 +0100
Update building page. Java 11 & svn -> git
---
webapps/docs/building.xml | 18 +-
webapps/docs/changelog.xml | 9 +
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/webapps/docs/building.xml b/webapps/docs/building.xml
index 450d5e50ca..a8a2f933a0 100644
--- a/webapps/docs/building.xml
+++ b/webapps/docs/building.xml
@@ -43,12 +43,12 @@ The following is a quick step by step guide.
-
+
-Building Apache Tomcat requires a JDK (version 8) to be installed. You can
download one from
-http://www.oracle.com/technetwork/java/javase/downloads/index.html;>http://www.oracle.com/technetwork/java/javase/downloads/index.html
-http://openjdk.java.net/install/index.html;>http://openjdk.java.net/install/index.html
+Building Apache Tomcat requires a JDK (version 11) or later to be installed.
You
+can download one from
+https://adoptium.net/temurin/releases;>https://adoptium.net/temurin/releases
or another JDK vendor.
@@ -83,11 +83,11 @@ available, which will be used to actually perform the build.
-
+
- Tomcat SVN repository URL:
- https://svn.apache.org/repos/asf/tomcat/trunk/;>https://svn.apache.org/repos/asf/tomcat/trunk/
+ Tomcat Git repository URL:
+ https://github.com/apache/tomcat;>https://github.com/apache/tomcat
Tomcat source packages:
@@ -95,8 +95,8 @@ available, which will be used to actually perform the build.
- Checkout the source using SVN, selecting a tag for released version or
- trunk for the current development code, or download and unpack a
+ Clone the source repository using Git, selecting a tag for released version
or
+ 9.0.x for the current development code, or download and unpack a
source package. For the remainder of this guide, the symbolic name
${tomcat.source} is used to refer to the
location where the source has been placed.
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 489f2a65c7..c199962f40 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+66064: Update the building page in the documentation web
+application to reflect changes in required Java version and source
+repository. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.0.x updated: Update building page. Java 11 & svn -> git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new cb24085098 Update building page. Java 11 & svn -> git
cb24085098 is described below
commit cb24085098f7fbeb23e01a8977bf899cc43be8ad
Author: Mark Thomas
AuthorDate: Mon May 16 18:49:29 2022 +0100
Update building page. Java 11 & svn -> git
---
webapps/docs/building.xml | 18 +-
webapps/docs/changelog.xml | 9 +
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/webapps/docs/building.xml b/webapps/docs/building.xml
index 450d5e50ca..697ecbb5b3 100644
--- a/webapps/docs/building.xml
+++ b/webapps/docs/building.xml
@@ -43,12 +43,12 @@ The following is a quick step by step guide.
-
+
-Building Apache Tomcat requires a JDK (version 8) to be installed. You can
download one from
-http://www.oracle.com/technetwork/java/javase/downloads/index.html;>http://www.oracle.com/technetwork/java/javase/downloads/index.html
-http://openjdk.java.net/install/index.html;>http://openjdk.java.net/install/index.html
+Building Apache Tomcat requires a JDK (version 11) or later to be installed.
You
+can download one from
+https://adoptium.net/temurin/releases;>https://adoptium.net/temurin/releases
or another JDK vendor.
@@ -83,11 +83,11 @@ available, which will be used to actually perform the build.
-
+
- Tomcat SVN repository URL:
- https://svn.apache.org/repos/asf/tomcat/trunk/;>https://svn.apache.org/repos/asf/tomcat/trunk/
+ Tomcat Git repository URL:
+ https://github.com/apache/tomcat;>https://github.com/apache/tomcat
Tomcat source packages:
@@ -95,8 +95,8 @@ available, which will be used to actually perform the build.
- Checkout the source using SVN, selecting a tag for released version or
- trunk for the current development code, or download and unpack a
+ Clone the source repository using Git, selecting a tag for released version
or
+ 10.0.x for the current development code, or download and unpack a
source package. For the remainder of this guide, the symbolic name
${tomcat.source} is used to refer to the
location where the source has been placed.
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 1bac51d6af..ef7823a8d1 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+66064: Update the building page in the documentation web
+application to reflect changes in required Java version and source
+repository. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Update building page. Java 11 & svn -> git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new d4008c0b65 Update building page. Java 11 & svn -> git
d4008c0b65 is described below
commit d4008c0b650da0b91d09656d0111b9ea01541f05
Author: Mark Thomas
AuthorDate: Mon May 16 18:49:29 2022 +0100
Update building page. Java 11 & svn -> git
---
webapps/docs/building.xml | 18 +-
webapps/docs/changelog.xml | 9 +
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/webapps/docs/building.xml b/webapps/docs/building.xml
index 450d5e50ca..d531a5c305 100644
--- a/webapps/docs/building.xml
+++ b/webapps/docs/building.xml
@@ -43,12 +43,12 @@ The following is a quick step by step guide.
-
+
-Building Apache Tomcat requires a JDK (version 8) to be installed. You can
download one from
-http://www.oracle.com/technetwork/java/javase/downloads/index.html;>http://www.oracle.com/technetwork/java/javase/downloads/index.html
-http://openjdk.java.net/install/index.html;>http://openjdk.java.net/install/index.html
+Building Apache Tomcat requires a JDK (version 11) or later to be installed.
You
+can download one from
+https://adoptium.net/temurin/releases;>https://adoptium.net/temurin/releases
or another JDK vendor.
@@ -83,11 +83,11 @@ available, which will be used to actually perform the build.
-
+
- Tomcat SVN repository URL:
- https://svn.apache.org/repos/asf/tomcat/trunk/;>https://svn.apache.org/repos/asf/tomcat/trunk/
+ Tomcat Git repository URL:
+ https://github.com/apache/tomcat;>https://github.com/apache/tomcat
Tomcat source packages:
@@ -95,8 +95,8 @@ available, which will be used to actually perform the build.
- Checkout the source using SVN, selecting a tag for released version or
- trunk for the current development code, or download and unpack a
+ Clone the source repository using Git, selecting a tag for released version
or
+ main for the current development code, or download and unpack a
source package. For the remainder of this guide, the symbolic name
${tomcat.source} is used to refer to the
location where the source has been placed.
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 9a2b0d0587..9b3df11a8b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+66064: Update the building page in the documentation web
+application to reflect changes in required Java version and source
+repository. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git push ERROR wrt. CI
Am 21.04.2022 um 09:56 schrieb Mark Thomas: On 20/04/2022 22:52, Rainer Jung wrote: I currently see ERROR messages when doing git push. The push itself seems to work and triggers eg. travis, but the error seems related with CI. Example: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 2 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 349 bytes | 43.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: To github:apache/tomcat.git remote: 7c0dd42ac4..9c8c76378e 9c8c76378ed0d48ecdcb586d9a0a2cd83820da78 -> main remote: Syncing refs/heads/main... remote: Sending notification emails to: ['"dev@tomcat.apache.org" '] and then the error: remote: git_buildbot: ERROR: Could not connect to ci2.apache.org:9989: Unicode-objects must be encoded before hashing To https://gitbox.apache.org/repos/asf/tomcat 7c0dd42ac4..9c8c76378e main -> main It happened for all branches. Does anyone know whether that's a problem and what needs to be done? It looks like we haven't had any CI builds triggered by commits for several weeks. I suspect the error you see above is the cause. My recommendation is that you open an INFRA ticket to report the issue. Thanks Mark, done: https://issues.apache.org/jira/browse/INFRA-23180 Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git push ERROR wrt. CI
On 20/04/2022 22:52, Rainer Jung wrote: I currently see ERROR messages when doing git push. The push itself seems to work and triggers eg. travis, but the error seems related with CI. Example: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 2 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 349 bytes | 43.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: To github:apache/tomcat.git remote: 7c0dd42ac4..9c8c76378e 9c8c76378ed0d48ecdcb586d9a0a2cd83820da78 -> main remote: Syncing refs/heads/main... remote: Sending notification emails to: ['"dev@tomcat.apache.org" '] and then the error: remote: git_buildbot: ERROR: Could not connect to ci2.apache.org:9989: Unicode-objects must be encoded before hashing To https://gitbox.apache.org/repos/asf/tomcat 7c0dd42ac4..9c8c76378e main -> main It happened for all branches. Does anyone know whether that's a problem and what needs to be done? It looks like we haven't had any CI builds triggered by commits for several weeks. I suspect the error you see above is the cause. My recommendation is that you open an INFRA ticket to report the issue. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
git push ERROR wrt. CI
I currently see ERROR messages when doing git push. The push itself seems to work and triggers eg. travis, but the error seems related with CI. Example: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 2 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 349 bytes | 43.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: To github:apache/tomcat.git remote:7c0dd42ac4..9c8c76378e 9c8c76378ed0d48ecdcb586d9a0a2cd83820da78 -> main remote: Syncing refs/heads/main... remote: Sending notification emails to: ['"dev@tomcat.apache.org" '] and then the error: remote: git_buildbot: ERROR: Could not connect to ci2.apache.org:9989: Unicode-objects must be encoded before hashing To https://gitbox.apache.org/repos/asf/tomcat 7c0dd42ac4..9c8c76378e main -> main It happened for all branches. Does anyone know whether that's a problem and what needs to be done? Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] branch main updated: Fix script so it works with current git layout
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/main by this push:
new 2133b43 Fix script so it works with current git layout
2133b43 is described below
commit 2133b4383672df280e6b7a868607d004142a3422
Author: Mark Thomas
AuthorDate: Wed Mar 16 19:32:10 2022 +
Fix script so it works with current git layout
---
jnirelease.sh | 8
xdocs/miscellaneous/changelog.xml | 3 +++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/jnirelease.sh b/jnirelease.sh
index 6763b28..2246585 100755
--- a/jnirelease.sh
+++ b/jnirelease.sh
@@ -162,11 +162,11 @@ else
git checkout ${JKJNIHASH}
fi
-if [ ! -d .git/refs/remotes/10.0.x ]; then
-git remote add -f 10.0.x ${TCJAVA_GITBASE}
+if [ ! -d .git/refs/remotes/tcjava ]; then
+git remote add -f tcjava ${TCJAVA_GITBASE}
fi
-git remote update 10.0.x
-diffcount=`git diff HEAD remotes/10.0.x/main java/org/apache/tomcat/jni | wc
-l`
+git remote update tcjava
+diffcount=`git diff HEAD remotes/tcjava/10.0.x java/org/apache/tomcat/jni | wc
-l`
if [ $diffcount -ne 0 ]; then
echo "WARNING: git subtree is not up to date with"
diff --git a/xdocs/miscellaneous/changelog.xml
b/xdocs/miscellaneous/changelog.xml
index d749412..f886dee 100644
--- a/xdocs/miscellaneous/changelog.xml
+++ b/xdocs/miscellaneous/changelog.xml
@@ -39,6 +39,9 @@
Update recommended OpenSSL version to 1.1.1n or later. (markt)
+
+ Fix release script so it works with the current git layout. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] 02/03: Tweak patch so it can be applied with git apply
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git commit e3259817ba2b18fc69376f6734ba01a05175a7d7 Author: Mark Thomas AuthorDate: Thu May 27 16:35:35 2021 +0100 Tweak patch so it can be applied with git apply --- native/srclib/apr/apr-enable-ipv6.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/native/srclib/apr/apr-enable-ipv6.patch b/native/srclib/apr/apr-enable-ipv6.patch index 26257ed..a58721c 100644 --- a/native/srclib/apr/apr-enable-ipv6.patch +++ b/native/srclib/apr/apr-enable-ipv6.patch @@ -1,5 +1,5 @@ include/apr.hw -+++ include/apr.hw +--- /include/apr.hw /include/apr.hw @@ -367,7 +367,7 @@ /* If we have a TCP implementation that can be "corked", what flag * do we use? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Correct Git branch used for 9.0.x
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new 4e249e8 Correct Git branch used for 9.0.x 4e249e8 is described below commit 4e249e831d2e1ee351e3f0122ed1c7e6af3350e5 Author: Mark Thomas AuthorDate: Thu Apr 8 11:11:23 2021 +0100 Correct Git branch used for 9.0.x --- build.properties.default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.properties.default b/build.properties.default index b4101c0..94b5663 100644 --- a/build.properties.default +++ b/build.properties.default @@ -35,7 +35,7 @@ version.suffix=-dev #ant.tstamp.now=1616047200 # - Source control flags - -git.branch=master +git.branch=9.0.x # - Build control flags - # Note enabling validation uses Checkstyle which is LGPL licensed - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Moving tomcat-maven-plugin from svn master to git master
On 17/02/2021 18:21, Konstantin Kolinko wrote: > ср, 17 февр. 2021 г. в 20:57, Konstantin Kolinko : >> >> ср, 17 февр. 2021 г. в 19:55, Mark Thomas : >>> >>> Hi all, >>> >>> If there are no objections, I plan to move the module to using git as >>> the master and updating the infrastructure accordingly. >> >> +1 to move to Git. >> >> IIRC we did not ask Infra to restore mirroring for this repo since the >> September 2019 crash of the service [1], but last commits to this >> project were in May 2019 and have already been mirrored. >> >> Comparing the current Subversion repository [2] with the Git mirror >> [3], I verified that >> >> 1) Both "trunk" and "tc8.x" branches are present in Git, with the >> latest commits from Subversion. >> 2) The files at the top of "trunk" and "tc8.x" branches are the same >> between Subversion and Git, except some LF/CRLF line ending >> differences. >> 3) All 4 tags from Subversion are present > > Comparing the files in tags between Subversion and Git: > - Tags "tomcat-maven-plugin-2.0", "tomcat-maven-plugin-2.1", > "tomcat-maven-plugin-2.2" - OK, no differences except line endings. > - Tag "tomcat-maven-plugin-2.0-beta-1" - OK. Except line endings the > files also differ on lines that contain the "Id" keyword. This is an > expected difference when this feature is used. Sample file: > common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/deployer/TomcatManager.java > >> Two glitches noted: >> >> 1) The git mirror has the following additional branch: >> - dependabot/maven/org.apache.httpcomponents-httpclient-4.3.6 >> >> 2) In trunk branch the following file has mixed line endings >> (line 44 apparently has a LF, while the rest are CRLF) >> src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/AbstractDeployWarMojo.java >> >> >> I think that the glitches can be ignored and we can use the existing >> mirror as is, without a resync. The git mirror has a number of pull >> requests in it (14 open, 18 closed ones). It would be nice to preserve >> them. >> >> [1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git >> >> [2] https://svn.apache.org/repos/asf/tomcat/maven-plugin/ >> [3] https://github.com/apache/tomcat-maven-plugin/ Thanks for all the checks. I've completed the switch and cleaned up the various infra bits and pieces that needed cleaning up. It might take up to 60 mins before we can commit to the repo but I doubt that is an issue. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Moving tomcat-maven-plugin from svn master to git master
ср, 17 февр. 2021 г. в 20:57, Konstantin Kolinko : > > ср, 17 февр. 2021 г. в 19:55, Mark Thomas : > > > > Hi all, > > > > If there are no objections, I plan to move the module to using git as > > the master and updating the infrastructure accordingly. > > +1 to move to Git. > > IIRC we did not ask Infra to restore mirroring for this repo since the > September 2019 crash of the service [1], but last commits to this > project were in May 2019 and have already been mirrored. > > Comparing the current Subversion repository [2] with the Git mirror > [3], I verified that > > 1) Both "trunk" and "tc8.x" branches are present in Git, with the > latest commits from Subversion. > 2) The files at the top of "trunk" and "tc8.x" branches are the same > between Subversion and Git, except some LF/CRLF line ending > differences. > 3) All 4 tags from Subversion are present Comparing the files in tags between Subversion and Git: - Tags "tomcat-maven-plugin-2.0", "tomcat-maven-plugin-2.1", "tomcat-maven-plugin-2.2" - OK, no differences except line endings. - Tag "tomcat-maven-plugin-2.0-beta-1" - OK. Except line endings the files also differ on lines that contain the "Id" keyword. This is an expected difference when this feature is used. Sample file: common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/deployer/TomcatManager.java > Two glitches noted: > > 1) The git mirror has the following additional branch: > - dependabot/maven/org.apache.httpcomponents-httpclient-4.3.6 > > 2) In trunk branch the following file has mixed line endings > (line 44 apparently has a LF, while the rest are CRLF) > src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/AbstractDeployWarMojo.java > > > I think that the glitches can be ignored and we can use the existing > mirror as is, without a resync. The git mirror has a number of pull > requests in it (14 open, 18 closed ones). It would be nice to preserve > them. > > [1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git > > [2] https://svn.apache.org/repos/asf/tomcat/maven-plugin/ > [3] https://github.com/apache/tomcat-maven-plugin/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Moving tomcat-maven-plugin from svn master to git master
ср, 17 февр. 2021 г. в 19:55, Mark Thomas : > > Hi all, > > I was chatting with a potential contributor to the tomcat-maven-plugin > project in the ASF-OGC-OSGeo code sprint. We wnet looking for the source wnet -> went > and he found an old mirror on github. I noticed that it is still > configured to use the now defunct svn->git mirroring service. > > If there are no objections, I plan to move the module to using git as > the master and updating the infrastructure accordingly. +1 to move to Git. IIRC we did not ask Infra to restore mirroring for this repo since the September 2019 crash of the service [1], but last commits to this project were in May 2019 and have already been mirrored. Comparing the current Subversion repository [2] with the Git mirror [3], I verified that 1) Both "trunk" and "tc8.x" branches are present in Git, with the latest commits from Subversion. 2) The files at the top of "trunk" and "tc8.x" branches are the same between Subversion and Git, except some LF/CRLF line ending differences. 3) All 4 tags from Subversion are present Two glitches noted: 1) The git mirror has the following additional branch: - dependabot/maven/org.apache.httpcomponents-httpclient-4.3.6 2) In trunk branch the following file has mixed line endings (line 44 apparently has a LF, while the rest are CRLF) src/main/java/org/apache/tomcat/maven/plugin/tomcat7/deploy/AbstractDeployWarMojo.java I think that the glitches can be ignored and we can use the existing mirror as is, without a resync. The git mirror has a number of pull requests in it (14 open, 18 closed ones). It would be nice to preserve them. [1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git [2] https://svn.apache.org/repos/asf/tomcat/maven-plugin/ [3] https://github.com/apache/tomcat-maven-plugin/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Moving tomcat-maven-plugin from svn master to git master
Hi all, I was chatting with a potential contributor to the tomcat-maven-plugin project in the ASF-OGC-OSGeo code sprint. We wnet looking for the source and he found an old mirror on github. I noticed that it is still configured to use the now defunct svn->git mirroring service. If there are no objections, I plan to move the module to using git as the master and updating the infrastructure accordingly. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn/git for website
On 29/10/2020 19:27, Igal Sapir wrote: > Dave, > > On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher wrote: > >> Hi - >> >> I may have helpful ideas. Tell me where the Tomcst site repository and >> build are located. >> > > The SVN repo for the Tomcat site is at > http://svn.apache.org/repos/asf/tomcat/site/ > > I'm not sure where the build scripts are stored or executed from. There is no automated build. Committers run the scripts locally when the site needs updating. Details in the read me file in the root of the repo. Mark > > Thanks, > > Igal > > > >> >> Regards, >> Dave >> >> Sent from my iPhone >> >>> On Oct 27, 2020, at 12:18 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >>> >>> Konstantin, >>> >>>> On 10/26/20 20:47, Konstantin Kolinko wrote: >>>> пт, 2 окт. 2020 г. в 00:09, Mark Thomas : >>>>> >>>>> Hi all, >>>>> >>>>> The topic came up at the BoF session at the end of the Tomcat track of >>>>> migrating the website from svn to git. There were strong opinions both >>>>> for migrating and for sticking with svn. >>>>> >>>>> As a middle ground I'd like to propose we ask Infra to create a git >>>>> mirror of the svn repo. >>>>> >>>>> For those who favour git: >>>>> The git mirror would be read-only but it would be possible to: >>>>> - clone the git mirror >>>>> - make changes in git >>>>> - use git-svn to commit those changes back to svn >>>>> - then the mirror automatically replicates them back to git >>>>> >>>>> For those who favour svn there would be no change. >>>>> >>>>> If there is agreement on this approach, I volunteer to contact infra to >>>>> get it set up. >>>> My proposal at BoF was for a partial mirror. >>>> The issue is that >>>> 1. I think that this mirror is intended as a tool to collect feedback >>>> / patches from random people, and to lower barriers for contribution. >>>> 2. The full Tomcat site is large. It includes documentation for all >>>> versions of Tomcat, including javadocs. Those pages are changed rarely >>>> and are not needed for people who contribute small changes for the >>>> site. The source code for those pages is elsewhere. >>> >>> The question I have to ask, here is: why do we bother putting all those >> files in revision-control? The users guide for 4 different versions of >> Tomcat is not a problem, but the javadocs are just stupid to store. >>> >>> Is there some policy we are following by having all those files in >> there? Or is it just to make sure that website "publication" is as simple >> as "svn checkout"? >>> >>>> 3. Subversion has easy commands to cope with such large source trees. >>>> This feature is called "sparse checkouts". >>>> For our site the necessary commands are documented in README.txt. >>>> Essentially, it is done with --depth and --set-depth arguments to "svn >>>> checkout" and "svn update" commands >>>> Speaking about Git, there are huge repositories [1] out there, but I >>>> think that the majority of people are not accustomed to them. >>>> [1] https://en.wikipedia.org/wiki/Monorepo >>>> I see that Git developers recently did some work to make dealing with >>>> such repositories simpler, with addition of "git sparse-checkout" >>>> command in Git 2.25.0 [2], released in January 2020. >>>> [2] >> https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt >>>> Though I think that support in tools is still lacking. E.g. missing in >>>> TortoiseGit. [3] >>>> [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 >>>> If we go with a full Git mirror or with migration to Git, then I think >>>> that somebody has to prepare an update to README.txt. >>>> If we go with a partial Git mirror, I think it could be named >>>> "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror >>>> if we ever make one. >>>> Ignored paths for git-svn are configured with "--ignore-paths" >>>> argument or with "svn-remote..ignore-paths" configuration >
Re: svn/git for website
Dave, On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher wrote: > Hi - > > I may have helpful ideas. Tell me where the Tomcst site repository and > build are located. > The SVN repo for the Tomcat site is at http://svn.apache.org/repos/asf/tomcat/site/ I'm not sure where the build scripts are stored or executed from. Thanks, Igal > > Regards, > Dave > > Sent from my iPhone > > > On Oct 27, 2020, at 12:18 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > > Konstantin, > > > >> On 10/26/20 20:47, Konstantin Kolinko wrote: > >> пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > >>> > >>> Hi all, > >>> > >>> The topic came up at the BoF session at the end of the Tomcat track of > >>> migrating the website from svn to git. There were strong opinions both > >>> for migrating and for sticking with svn. > >>> > >>> As a middle ground I'd like to propose we ask Infra to create a git > >>> mirror of the svn repo. > >>> > >>> For those who favour git: > >>> The git mirror would be read-only but it would be possible to: > >>> - clone the git mirror > >>> - make changes in git > >>> - use git-svn to commit those changes back to svn > >>> - then the mirror automatically replicates them back to git > >>> > >>> For those who favour svn there would be no change. > >>> > >>> If there is agreement on this approach, I volunteer to contact infra to > >>> get it set up. > >> My proposal at BoF was for a partial mirror. > >> The issue is that > >> 1. I think that this mirror is intended as a tool to collect feedback > >> / patches from random people, and to lower barriers for contribution. > >> 2. The full Tomcat site is large. It includes documentation for all > >> versions of Tomcat, including javadocs. Those pages are changed rarely > >> and are not needed for people who contribute small changes for the > >> site. The source code for those pages is elsewhere. > > > > The question I have to ask, here is: why do we bother putting all those > files in revision-control? The users guide for 4 different versions of > Tomcat is not a problem, but the javadocs are just stupid to store. > > > > Is there some policy we are following by having all those files in > there? Or is it just to make sure that website "publication" is as simple > as "svn checkout"? > > > >> 3. Subversion has easy commands to cope with such large source trees. > >> This feature is called "sparse checkouts". > >> For our site the necessary commands are documented in README.txt. > >> Essentially, it is done with --depth and --set-depth arguments to "svn > >> checkout" and "svn update" commands > >> Speaking about Git, there are huge repositories [1] out there, but I > >> think that the majority of people are not accustomed to them. > >> [1] https://en.wikipedia.org/wiki/Monorepo > >> I see that Git developers recently did some work to make dealing with > >> such repositories simpler, with addition of "git sparse-checkout" > >> command in Git 2.25.0 [2], released in January 2020. > >> [2] > https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt > >> Though I think that support in tools is still lacking. E.g. missing in > >> TortoiseGit. [3] > >> [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 > >> If we go with a full Git mirror or with migration to Git, then I think > >> that somebody has to prepare an update to README.txt. > >> If we go with a partial Git mirror, I think it could be named > >> "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror > >> if we ever make one. > >> Ignored paths for git-svn are configured with "--ignore-paths" > >> argument or with "svn-remote..ignore-paths" configuration > >> option. [4] > >> [4] https://git-scm.com/docs/git-svn > >> Other notes: > >> 4. Release managers use Subversion to publish the binaries. > >> Thus I expect that they are able to update the published documentation > >> with Subversion as well. > >> 5. Publishing the javadocs generates small changes over a large number > >> of files. The script that generates the commit email notes that the > >> diff is huge and trims it all to a small summary. > >> If we ever migrate to Git, I wonder whether a similar script in Git is > >> able to cope with it. > > > > We might also want to consider complicating the website-building process > in order to simplify the repository. Yes, "disk space is cheap" but it's > kind of ridiculous that we have all that derivative content in RCS, > separate from its canonical source. > > > > -chris > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: svn/git for website
Hi - I may have helpful ideas. Tell me where the Tomcst site repository and build are located. Regards, Dave Sent from my iPhone > On Oct 27, 2020, at 12:18 PM, Christopher Schultz > wrote: > > Konstantin, > >> On 10/26/20 20:47, Konstantin Kolinko wrote: >> пт, 2 окт. 2020 г. в 00:09, Mark Thomas : >>> >>> Hi all, >>> >>> The topic came up at the BoF session at the end of the Tomcat track of >>> migrating the website from svn to git. There were strong opinions both >>> for migrating and for sticking with svn. >>> >>> As a middle ground I'd like to propose we ask Infra to create a git >>> mirror of the svn repo. >>> >>> For those who favour git: >>> The git mirror would be read-only but it would be possible to: >>> - clone the git mirror >>> - make changes in git >>> - use git-svn to commit those changes back to svn >>> - then the mirror automatically replicates them back to git >>> >>> For those who favour svn there would be no change. >>> >>> If there is agreement on this approach, I volunteer to contact infra to >>> get it set up. >> My proposal at BoF was for a partial mirror. >> The issue is that >> 1. I think that this mirror is intended as a tool to collect feedback >> / patches from random people, and to lower barriers for contribution. >> 2. The full Tomcat site is large. It includes documentation for all >> versions of Tomcat, including javadocs. Those pages are changed rarely >> and are not needed for people who contribute small changes for the >> site. The source code for those pages is elsewhere. > > The question I have to ask, here is: why do we bother putting all those files > in revision-control? The users guide for 4 different versions of Tomcat is > not a problem, but the javadocs are just stupid to store. > > Is there some policy we are following by having all those files in there? Or > is it just to make sure that website "publication" is as simple as "svn > checkout"? > >> 3. Subversion has easy commands to cope with such large source trees. >> This feature is called "sparse checkouts". >> For our site the necessary commands are documented in README.txt. >> Essentially, it is done with --depth and --set-depth arguments to "svn >> checkout" and "svn update" commands >> Speaking about Git, there are huge repositories [1] out there, but I >> think that the majority of people are not accustomed to them. >> [1] https://en.wikipedia.org/wiki/Monorepo >> I see that Git developers recently did some work to make dealing with >> such repositories simpler, with addition of "git sparse-checkout" >> command in Git 2.25.0 [2], released in January 2020. >> [2] https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt >> Though I think that support in tools is still lacking. E.g. missing in >> TortoiseGit. [3] >> [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 >> If we go with a full Git mirror or with migration to Git, then I think >> that somebody has to prepare an update to README.txt. >> If we go with a partial Git mirror, I think it could be named >> "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror >> if we ever make one. >> Ignored paths for git-svn are configured with "--ignore-paths" >> argument or with "svn-remote..ignore-paths" configuration >> option. [4] >> [4] https://git-scm.com/docs/git-svn >> Other notes: >> 4. Release managers use Subversion to publish the binaries. >> Thus I expect that they are able to update the published documentation >> with Subversion as well. >> 5. Publishing the javadocs generates small changes over a large number >> of files. The script that generates the commit email notes that the >> diff is huge and trims it all to a small summary. >> If we ever migrate to Git, I wonder whether a similar script in Git is >> able to cope with it. > > We might also want to consider complicating the website-building process in > order to simplify the repository. Yes, "disk space is cheap" but it's kind of > ridiculous that we have all that derivative content in RCS, separate from its > canonical source. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn/git for website
On Tue, Oct 27, 2020 at 12:17 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Konstantin, > > On 10/26/20 20:47, Konstantin Kolinko wrote: > > пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > >> > >> Hi all, > >> > >> The topic came up at the BoF session at the end of the Tomcat track of > >> migrating the website from svn to git. There were strong opinions both > >> for migrating and for sticking with svn. > >> > >> As a middle ground I'd like to propose we ask Infra to create a git > >> mirror of the svn repo. > >> > >> For those who favour git: > >> The git mirror would be read-only but it would be possible to: > >> - clone the git mirror > >> - make changes in git > >> - use git-svn to commit those changes back to svn > >> - then the mirror automatically replicates them back to git > >> > >> For those who favour svn there would be no change. > >> > >> If there is agreement on this approach, I volunteer to contact infra to > >> get it set up. > > > > My proposal at BoF was for a partial mirror. > > > > The issue is that > > > > 1. I think that this mirror is intended as a tool to collect feedback > > / patches from random people, and to lower barriers for contribution. > > > > 2. The full Tomcat site is large. It includes documentation for all > > versions of Tomcat, including javadocs. Those pages are changed rarely > > and are not needed for people who contribute small changes for the > > site. The source code for those pages is elsewhere. > > The question I have to ask, here is: why do we bother putting all those > files in revision-control? The users guide for 4 different versions of > Tomcat is not a problem, but the javadocs are just stupid to store. > > Is there some policy we are following by having all those files in > there? Or is it just to make sure that website "publication" is as > simple as "svn checkout"? > > > 3. Subversion has easy commands to cope with such large source trees. > > This feature is called "sparse checkouts". > > > > For our site the necessary commands are documented in README.txt. > > Essentially, it is done with --depth and --set-depth arguments to "svn > > checkout" and "svn update" commands > > > > Speaking about Git, there are huge repositories [1] out there, but I > > think that the majority of people are not accustomed to them. > > > > [1] https://en.wikipedia.org/wiki/Monorepo > > > > I see that Git developers recently did some work to make dealing with > > such repositories simpler, with addition of "git sparse-checkout" > > command in Git 2.25.0 [2], released in January 2020. > > > > [2] > https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt > > > > Though I think that support in tools is still lacking. E.g. missing in > > TortoiseGit. [3] > > > > [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 > > > > > > If we go with a full Git mirror or with migration to Git, then I think > > that somebody has to prepare an update to README.txt. > > > > If we go with a partial Git mirror, I think it could be named > > "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror > > if we ever make one. > > > > > > Ignored paths for git-svn are configured with "--ignore-paths" > > argument or with "svn-remote..ignore-paths" configuration > > option. [4] > > > > [4] https://git-scm.com/docs/git-svn > > > > > > Other notes: > > > > 4. Release managers use Subversion to publish the binaries. > > > > Thus I expect that they are able to update the published documentation > > with Subversion as well. > > > > 5. Publishing the javadocs generates small changes over a large number > > of files. The script that generates the commit email notes that the > > diff is huge and trims it all to a small summary. > > > > If we ever migrate to Git, I wonder whether a similar script in Git is > > able to cope with it. > > We might also want to consider complicating the website-building process > in order to simplify the repository. Yes, "disk space is cheap" but it's > kind of ridiculous that we have all that derivative content in RCS, > separate from its canonical source. > That makes a lot of sense to me. I'm sure that the whole process can be scripted, including the script that Konstantin mentioned
Re: svn/git for website
Konstantin, On 10/26/20 20:47, Konstantin Kolinko wrote: пт, 2 окт. 2020 г. в 00:09, Mark Thomas : Hi all, The topic came up at the BoF session at the end of the Tomcat track of migrating the website from svn to git. There were strong opinions both for migrating and for sticking with svn. As a middle ground I'd like to propose we ask Infra to create a git mirror of the svn repo. For those who favour git: The git mirror would be read-only but it would be possible to: - clone the git mirror - make changes in git - use git-svn to commit those changes back to svn - then the mirror automatically replicates them back to git For those who favour svn there would be no change. If there is agreement on this approach, I volunteer to contact infra to get it set up. My proposal at BoF was for a partial mirror. The issue is that 1. I think that this mirror is intended as a tool to collect feedback / patches from random people, and to lower barriers for contribution. 2. The full Tomcat site is large. It includes documentation for all versions of Tomcat, including javadocs. Those pages are changed rarely and are not needed for people who contribute small changes for the site. The source code for those pages is elsewhere. The question I have to ask, here is: why do we bother putting all those files in revision-control? The users guide for 4 different versions of Tomcat is not a problem, but the javadocs are just stupid to store. Is there some policy we are following by having all those files in there? Or is it just to make sure that website "publication" is as simple as "svn checkout"? 3. Subversion has easy commands to cope with such large source trees. This feature is called "sparse checkouts". For our site the necessary commands are documented in README.txt. Essentially, it is done with --depth and --set-depth arguments to "svn checkout" and "svn update" commands Speaking about Git, there are huge repositories [1] out there, but I think that the majority of people are not accustomed to them. [1] https://en.wikipedia.org/wiki/Monorepo I see that Git developers recently did some work to make dealing with such repositories simpler, with addition of "git sparse-checkout" command in Git 2.25.0 [2], released in January 2020. [2] https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt Though I think that support in tools is still lacking. E.g. missing in TortoiseGit. [3] [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 If we go with a full Git mirror or with migration to Git, then I think that somebody has to prepare an update to README.txt. If we go with a partial Git mirror, I think it could be named "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror if we ever make one. Ignored paths for git-svn are configured with "--ignore-paths" argument or with "svn-remote..ignore-paths" configuration option. [4] [4] https://git-scm.com/docs/git-svn Other notes: 4. Release managers use Subversion to publish the binaries. Thus I expect that they are able to update the published documentation with Subversion as well. 5. Publishing the javadocs generates small changes over a large number of files. The script that generates the commit email notes that the diff is huge and trims it all to a small summary. If we ever migrate to Git, I wonder whether a similar script in Git is able to cope with it. We might also want to consider complicating the website-building process in order to simplify the repository. Yes, "disk space is cheap" but it's kind of ridiculous that we have all that derivative content in RCS, separate from its canonical source. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn/git for website
пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > > Hi all, > > The topic came up at the BoF session at the end of the Tomcat track of > migrating the website from svn to git. There were strong opinions both > for migrating and for sticking with svn. > > As a middle ground I'd like to propose we ask Infra to create a git > mirror of the svn repo. > > For those who favour git: > The git mirror would be read-only but it would be possible to: > - clone the git mirror > - make changes in git > - use git-svn to commit those changes back to svn > - then the mirror automatically replicates them back to git > > For those who favour svn there would be no change. > > If there is agreement on this approach, I volunteer to contact infra to > get it set up. My proposal at BoF was for a partial mirror. The issue is that 1. I think that this mirror is intended as a tool to collect feedback / patches from random people, and to lower barriers for contribution. 2. The full Tomcat site is large. It includes documentation for all versions of Tomcat, including javadocs. Those pages are changed rarely and are not needed for people who contribute small changes for the site. The source code for those pages is elsewhere. 3. Subversion has easy commands to cope with such large source trees. This feature is called "sparse checkouts". For our site the necessary commands are documented in README.txt. Essentially, it is done with --depth and --set-depth arguments to "svn checkout" and "svn update" commands Speaking about Git, there are huge repositories [1] out there, but I think that the majority of people are not accustomed to them. [1] https://en.wikipedia.org/wiki/Monorepo I see that Git developers recently did some work to make dealing with such repositories simpler, with addition of "git sparse-checkout" command in Git 2.25.0 [2], released in January 2020. [2] https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt Though I think that support in tools is still lacking. E.g. missing in TortoiseGit. [3] [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 If we go with a full Git mirror or with migration to Git, then I think that somebody has to prepare an update to README.txt. If we go with a partial Git mirror, I think it could be named "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror if we ever make one. Ignored paths for git-svn are configured with "--ignore-paths" argument or with "svn-remote..ignore-paths" configuration option. [4] [4] https://git-scm.com/docs/git-svn Other notes: 4. Release managers use Subversion to publish the binaries. Thus I expect that they are able to update the published documentation with Subversion as well. 5. Publishing the javadocs generates small changes over a large number of files. The script that generates the commit email notes that the diff is huge and trims it all to a small summary. If we ever migrate to Git, I wonder whether a similar script in Git is able to cope with it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn/git for website
On Fri, Oct 2, 2020 at 12:09 AM Mark Thomas wrote: > Hi all, > > The topic came up at the BoF session at the end of the Tomcat track of > migrating the website from svn to git. There were strong opinions both > for migrating and for sticking with svn. > > As a middle ground I'd like to propose we ask Infra to create a git > mirror of the svn repo. > > For those who favour git: > The git mirror would be read-only but it would be possible to: > - clone the git mirror > - make changes in git > - use git-svn to commit those changes back to svn > - then the mirror automatically replicates them back to git > > For those who favour svn there would be no change. > > If there is agreement on this approach, I volunteer to contact infra to > get it set up. > > Thoughts? > My personal preference is to move to Git! Martin > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
svn/git for website
Hi all, The topic came up at the BoF session at the end of the Tomcat track of migrating the website from svn to git. There were strong opinions both for migrating and for sticking with svn. As a middle ground I'd like to propose we ask Infra to create a git mirror of the svn repo. For those who favour git: The git mirror would be read-only but it would be possible to: - clone the git mirror - make changes in git - use git-svn to commit those changes back to svn - then the mirror automatically replicates them back to git For those who favour svn there would be no change. If there is agreement on this approach, I volunteer to contact infra to get it set up. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 7.0.x updated: Use a link to TestTomcat in Git instead of SVN
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/7.0.x by this push:
new e487719 Use a link to TestTomcat in Git instead of SVN
e487719 is described below
commit e487719b1dff28babedb0eb7873f617b5180f996
Author: Martin Tzvetanov Grigorov
AuthorDate: Wed Sep 30 10:36:50 2020 +0300
Use a link to TestTomcat in Git instead of SVN
(cherry picked from commit 16181fc7b1930ff202ec2e475f2fbdc587f3e314)
---
java/org/apache/catalina/startup/Tomcat.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/Tomcat.java
b/java/org/apache/catalina/startup/Tomcat.java
index fd5652e..21120dd 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -149,7 +149,7 @@ import org.apache.tomcat.util.res.StringManager;
* see setters for doc. It can be used for simple tests and
* demo.
*
- * @see https://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
+ * @see https://gitbox.apache.org/repos/asf?p=tomcat.git;a=blob;f=test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
* @author Costin Manolache
*/
public class Tomcat {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Use a link to TestTomcat in Git instead of SVN
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new c08d2d4 Use a link to TestTomcat in Git instead of SVN
c08d2d4 is described below
commit c08d2d40616c8680a536375419f9719aae0a90ae
Author: Martin Tzvetanov Grigorov
AuthorDate: Wed Sep 30 10:36:50 2020 +0300
Use a link to TestTomcat in Git instead of SVN
(cherry picked from commit 16181fc7b1930ff202ec2e475f2fbdc587f3e314)
---
java/org/apache/catalina/startup/Tomcat.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/Tomcat.java
b/java/org/apache/catalina/startup/Tomcat.java
index 67e990d..50515dd 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -147,7 +147,7 @@ import org.apache.tomcat.util.res.StringManager;
* see setters for doc. It can be used for simple tests and
* demo.
*
- * @see https://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
+ * @see https://gitbox.apache.org/repos/asf?p=tomcat.git;a=blob;f=test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
* @author Costin Manolache
*/
public class Tomcat {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Use a link to TestTomcat in Git instead of SVN
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new f95fcd2 Use a link to TestTomcat in Git instead of SVN
f95fcd2 is described below
commit f95fcd204fae01d0034d1cdb8178082361850eec
Author: Martin Tzvetanov Grigorov
AuthorDate: Wed Sep 30 10:36:50 2020 +0300
Use a link to TestTomcat in Git instead of SVN
(cherry picked from commit 16181fc7b1930ff202ec2e475f2fbdc587f3e314)
---
java/org/apache/catalina/startup/Tomcat.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/Tomcat.java
b/java/org/apache/catalina/startup/Tomcat.java
index 0811492..88859e8 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -153,7 +153,7 @@ import org.apache.tomcat.util.res.StringManager;
* see setters for doc. It can be used for simple tests and
* demo.
*
- * @see https://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
+ * @see https://gitbox.apache.org/repos/asf?p=tomcat.git;a=blob;f=test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
* @author Costin Manolache
*/
public class Tomcat {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Use a link to TestTomcat in Git instead of SVN
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 16181fc Use a link to TestTomcat in Git instead of SVN
16181fc is described below
commit 16181fc7b1930ff202ec2e475f2fbdc587f3e314
Author: Martin Tzvetanov Grigorov
AuthorDate: Wed Sep 30 10:36:50 2020 +0300
Use a link to TestTomcat in Git instead of SVN
---
java/org/apache/catalina/startup/Tomcat.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/Tomcat.java
b/java/org/apache/catalina/startup/Tomcat.java
index db6fb8e..e5565d1 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -153,7 +153,7 @@ import org.apache.tomcat.util.res.StringManager;
* see setters for doc. It can be used for simple tests and
* demo.
*
- * @see https://svn.apache.org/repos/asf/tomcat/trunk/test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
+ * @see https://gitbox.apache.org/repos/asf?p=tomcat.git;a=blob;f=test/org/apache/catalina/startup/TestTomcat.java;>TestTomcat
* @author Costin Manolache
*/
public class Tomcat {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
На пт, 26.06.2020 г. в 23:41 Rémy Maucherat написа: > > On Fri, Jun 26, 2020 at 4:48 PM Mark Thomas wrote: >> >> Hi, >> >> Picking up this thread again I see a range of views. "main" seems to be >> the most popular although several folks suggested "10.0.x" and "use >> whatever GitHub use". There was also interest in "trunk". Particularly >> with the additional suggestion of "10.0.x" appearing in the middle of >> the discussion, I'm not sure where consensus lies at the moment. > > > I was used to trunk :) It seems GitHub has some plans for the renaming https://github.com/github/renaming Violeta > > Rémy > >> >> >> One suggestion I particularly liked was to do the rename at the point we >> branch 10.0.x and start on 10.1.x since we will need to be updating CI >> and various things anyway. That is currently looking like September as >> that is the target date for the Jakarta EE 9 release. >> >> I suspect that this could get tricky as I'd prefer "main" or "10.0.x", >> could work with "trunk" but really don't want to continue with "master". >> I imagine others have similar views in different combinations. Maybe if >> others express their views in a similar way to the above we'll end up >> with a natural consensus. If not, we'll have to figure something out. >> >> Mark >> >> >> >> On 19/06/2020 16:32, Emmanuel Bourg wrote: >> > Le 16/06/2020 à 10:02, Mark Thomas a écrit : >> > >> >> Thoughts? >> > >> > I'd prefer the status-quo and keep "master", I've always understood this >> > as the 'master record' (I know it might be historically wrong) and I >> > haven't seen evidences it has ever offended or deterred anyone from >> > contributing. >> > >> > If there is a consensus to change I suggest waiting to see what GitHub >> > plans to do. The "master" name is a de-facto standard for Git >> > repositories, and I think we should remain consistent with the new name >> > that will be popularized by GitHub. >> > >> > That said, I have a preference for "main". >> > >> > Emmanuel Bourg >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> > For additional commands, e-mail: dev-h...@tomcat.apache.org >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
On Fri, Jun 26, 2020 at 4:48 PM Mark Thomas wrote: > Hi, > > Picking up this thread again I see a range of views. "main" seems to be > the most popular although several folks suggested "10.0.x" and "use > whatever GitHub use". There was also interest in "trunk". Particularly > with the additional suggestion of "10.0.x" appearing in the middle of > the discussion, I'm not sure where consensus lies at the moment. > I was used to trunk :) Rémy > > One suggestion I particularly liked was to do the rename at the point we > branch 10.0.x and start on 10.1.x since we will need to be updating CI > and various things anyway. That is currently looking like September as > that is the target date for the Jakarta EE 9 release. > > I suspect that this could get tricky as I'd prefer "main" or "10.0.x", > could work with "trunk" but really don't want to continue with "master". > I imagine others have similar views in different combinations. Maybe if > others express their views in a similar way to the above we'll end up > with a natural consensus. If not, we'll have to figure something out. > > Mark > > > > On 19/06/2020 16:32, Emmanuel Bourg wrote: > > Le 16/06/2020 à 10:02, Mark Thomas a écrit : > > > >> Thoughts? > > > > I'd prefer the status-quo and keep "master", I've always understood this > > as the 'master record' (I know it might be historically wrong) and I > > haven't seen evidences it has ever offended or deterred anyone from > > contributing. > > > > If there is a consensus to change I suggest waiting to see what GitHub > > plans to do. The "master" name is a de-facto standard for Git > > repositories, and I think we should remain consistent with the new name > > that will be popularized by GitHub. > > > > That said, I have a preference for "main". > > > > Emmanuel Bourg > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Changing the name of the default branch in our git repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/26/20 10:48, Mark Thomas wrote: > Picking up this thread again I see a range of views. "main" seems > to be the most popular although several folks suggested "10.0.x" > and "use whatever GitHub use". There was also interest in "trunk". > Particularly with the additional suggestion of "10.0.x" appearing > in the middle of the discussion, I'm not sure where consensus lies > at the moment. > > One suggestion I particularly liked was to do the rename at the > point we branch 10.0.x and start on 10.1.x since we will need to be > updating CI and various things anyway. That is currently looking > like September as that is the target date for the Jakarta EE 9 > release. > > I suspect that this could get tricky as I'd prefer "main" or > "10.0.x", could work with "trunk" but really don't want to continue > with "master". I imagine others have similar views in different > combinations. Maybe if others express their views in a similar way > to the above we'll end up with a natural consensus. If not, we'll > have to figure something out. I understand the motivation to use more inclusive language, but IMO in the absence of the word "slave", this "master" branch is more analogous to a "master copy" of an artifact (usually recording) and reflects the true etymology of the term, here. If it's more convenient to make this change in September, then let's wait until then. Changing twice doesn't really help anybody and causes a certain amount of chaos. - -chris > On 19/06/2020 16:32, Emmanuel Bourg wrote: >> Le 16/06/2020 à 10:02, Mark Thomas a écrit : >> >>> Thoughts? >> >> I'd prefer the status-quo and keep "master", I've always >> understood this as the 'master record' (I know it might be >> historically wrong) and I haven't seen evidences it has ever >> offended or deterred anyone from contributing. >> >> If there is a consensus to change I suggest waiting to see what >> GitHub plans to do. The "master" name is a de-facto standard for >> Git repositories, and I think we should remain consistent with >> the new name that will be popularized by GitHub. >> >> That said, I have a preference for "main". >> >> Emmanuel Bourg >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl72WbcACgkQHPApP6U8 pFgzxQ//ZyTsETf5CjZ9S2CQ65GbSVY+FdhWB1Tuy6qrdmZgkII48PQWsu7SeFJL yCH0LM9DdMEmjBx9uoHWmFtOSxgPgAPGzqQYRsDcB2zwGpkyN/kHwFDVxRyBSy7Q NmRbE6K0orMalD86XjvFQlv/ClyOe4rNSbqywT8nw0zJFwiM2HVLJXV1CgvEor1k Z7uVd6f10mm/F4jxQxW2nQ0rvyiMaEEOKtnZG/nGL9kb5iLz/10LlFot1Wzg49Hf tbAbnH6k34u0OXkteYhbVNklhlGGMDKmbYCPUV+LJGZLl+pRb+Y6U1UDM22W+GCZ HnFYMPExDPj9QSd4C3sBWx8X7oT9fyf56puK0BqP3SQhAbKUp752f7y7bdLxoQq7 aQgZm3kvNH3Vk7tkSLtnroLGuZ7yelbZXtMqvLCgoX98JaoxqejUuSB7uL9zFZ/n Cu19NPxgRMSIyvrwredHhm2lDl0IBDeac/MeMwVplwb1VqLEZvrTdqwhg+Xe7NXo 2TilY/pLZhwnA/clyxwOo1wT+w/11s1tCMzZObSU5bVH1vbJH8Y6qVxot644Z303 QE5lPJprS6t/zIN3WVi6oSTcAo64fTdjIvlIUZ5oKakmclRvF0I2sWDt7d5m5CEI sdt7HBbH/gAZ1h96096Qp5PmyABFnaF1OmAkorKG94mAkQvQSO4= =l8h0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Hi, Picking up this thread again I see a range of views. "main" seems to be the most popular although several folks suggested "10.0.x" and "use whatever GitHub use". There was also interest in "trunk". Particularly with the additional suggestion of "10.0.x" appearing in the middle of the discussion, I'm not sure where consensus lies at the moment. One suggestion I particularly liked was to do the rename at the point we branch 10.0.x and start on 10.1.x since we will need to be updating CI and various things anyway. That is currently looking like September as that is the target date for the Jakarta EE 9 release. I suspect that this could get tricky as I'd prefer "main" or "10.0.x", could work with "trunk" but really don't want to continue with "master". I imagine others have similar views in different combinations. Maybe if others express their views in a similar way to the above we'll end up with a natural consensus. If not, we'll have to figure something out. Mark On 19/06/2020 16:32, Emmanuel Bourg wrote: > Le 16/06/2020 à 10:02, Mark Thomas a écrit : > >> Thoughts? > > I'd prefer the status-quo and keep "master", I've always understood this > as the 'master record' (I know it might be historically wrong) and I > haven't seen evidences it has ever offended or deterred anyone from > contributing. > > If there is a consensus to change I suggest waiting to see what GitHub > plans to do. The "master" name is a de-facto standard for Git > repositories, and I think we should remain consistent with the new name > that will be popularized by GitHub. > > That said, I have a preference for "main". > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Le 16/06/2020 à 10:02, Mark Thomas a écrit : > Thoughts? I'd prefer the status-quo and keep "master", I've always understood this as the 'master record' (I know it might be historically wrong) and I haven't seen evidences it has ever offended or deterred anyone from contributing. If there is a consensus to change I suggest waiting to see what GitHub plans to do. The "master" name is a de-facto standard for Git repositories, and I think we should remain consistent with the new name that will be popularized by GitHub. That said, I have a preference for "main". Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/16/20 04:02, Mark Thomas wrote: > All, > > You may have seen the recent discussions both inside and outside > the ASF about the user of "master" as the name of the default git > branch. If you haven't, the short version is that the name can be > traced back to master/slave and its associations with human > slavery. > > I'd like to propose that the Apache Tomcat project renames the > master branch in all of the project repositories. +1 > I think there are two front runners for the new name: > > - main - this looks to be the name GitHub and a number of OSS > projects will be switching to > > - trunk - reflects the Subversion heritage of both the project and > the ASF I'm not picky about the name, but perhaps there is an opportunity, here. Historically, trunk/master is where new development has been done, and releases of the current-latest version of Tomcat are released directly from that branch. Perhaps we could be more clear in that our new development branch is 10.whatever and not trunk/main/master/foo which just happens to cut releases called 10.x from it? Perhaps I am suggesting that we have main/trunk *and* 10.x but I haven't really thought it out. > Committers and contributors will rebase any local branches to > $new_branch A short set of instructions post-migration would be very helpful for me. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ssSQACgkQHPApP6U8 pFgp5g/8DNrNJk425nRu01rASo9TLLGqYcf5tVT27b+jFhLH9JnPFQJ6qDODN8QJ o8srgUHsiOnk/HNI+wxjfN2rklIP4gDEEJG8wsqvVQEuHbk3hxrXMHyKdOCENcsp NeuiIdXduJVmJAHHziXs7Aqddf6fnu4yFOBMbaq8uncRqrM0EUgJipMLax0FOBfG tpfp+oefynWyK/whoGGuWUkoiLSjhS6YlrJ2ElU18mztQsAZg1VtDpM1H4C4S9vC HIUoGlor8J14zo2DMt34kleo5YZDbgSbKJzhmXhqfpq0sGtFpUJSRoJjlieHsDMT T1AM12HOT6rXhTHLkxo8pl9ariM0ieHI/YtKDi5NlzHStwII3C0ZAcyPHTYGTeIb 7XFPP1mT7mEEUXW+g2fbpNyUNwceXO/zDg2NfEbUKN+yG94PWcY1tSgoLRrv9o2h /U81iM/rFZqxqZ+YOLtYoAcjVYaR106/fTCLeRMZWO7sgzknLHrDE52EoHA6cnkr ABkQX4fKt70V9oVf61v/0WuKyI2O3EB3R5Yc5NZgmx+gFoqSarE6HOX/5sOAPoHj /zFTUt19zf/6yyTLIQSbz/Sh6jzAhi44nVArNO4kX/S4w55jf7mJbZRiryhYW1xN gfwq9RvNtvR+r22NAlvKKRKJjMpslnAgbUDqENvuF+qurdrEgtg= =xOny -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
вт, 16 июн. 2020 г. в 11:02, Mark Thomas : > > All, > > You may have seen the recent discussions both inside and outside the ASF > about the user of "master" as the name of the default git branch. If you > haven't, the short version is that the name can be traced back to > master/slave and its associations with human slavery. > > I'd like to propose that the Apache Tomcat project renames the master > branch in all of the project repositories. > > I think there are two front runners for the new name: > > - main - this looks to be the name GitHub and a number of OSS projects > will be switching to > > - trunk - reflects the Subversion heritage of both the project and the > ASF > > Other options I have seen suggested include "default", "dev", "develop". > Other suggestions welcome. 1. My preference is for "trunk". To come back where it was for many years. It is a well known name that we used for a long time. 2. I do not like following the hype. I think a better moment to do a rename will be when 10.0.x is branched off as a separate branch. That is when some CI servers will have to be reconfigured. I think that will be about the time when 7.0.x reaches EOL, end of March 2021. http://tomcat.apache.org/tomcat-70-eol.html > This may help for the gradual migration > https://github.com/chancancode/branch-rename/#gradual-migration Looking at "Gradual Migration" strategy there, I wonder if maybe we could create a "10.0.x" branch now (using it as the new name, as suggested by Martin Grigorov). BTW, one step is missing there: one has to update the 'HEAD' ref in Git repository. It is a symbolic reference. GitHub does not show the file, but it can be seen at gitbox . https://gitbox.apache.org/repos/asf/tomcat.git/HEAD Best regards, Kostantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Hi, Do you know if there would be a redirect of existing PR and "existing" references to master or does it break the ecosystem for a while - if so I'm not sure it is worth it ? If it does not break anything "latest" does not sound that bad and likely avoids this superior/inferior thought people can have as with master or main and it sounds more modern than trunk ;). Indeed, just my 2 cents ;). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 16 juin 2020 à 17:36, Martin Grigorov a écrit : > Hi, > > On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas wrote: > >> All, >> >> You may have seen the recent discussions both inside and outside the ASF >> about the user of "master" as the name of the default git branch. If you >> haven't, the short version is that the name can be traced back to >> master/slave and its associations with human slavery. >> >> I'd like to propose that the Apache Tomcat project renames the master >> branch in all of the project repositories. >> >> I think there are two front runners for the new name: >> >> - main - this looks to be the name GitHub and a number of OSS projects >> will be switching to >> >> - trunk - reflects the Subversion heritage of both the project and the >> ASF >> >> Other options I have seen suggested include "default", "dev", "develop". >> Other suggestions welcome. >> >> Personally, I am leaning towards main as that looks to be the choice of >> the majority and using the majority choice will make it (a little bit) >> easier for new community members to find their way around the project. >> >> In terms of impact, changing the name is going to break stuff. It is >> really creating a new branch and deleting the old one. >> >> Deleting a branch triggers the automatic closure of github PRs against >> that branch. However if we create "$new_branch" we can edit the PRs to >> use "$new_branch" before we delete master. Given the small number of >> open PRs that is easily done. >> >> CI systems will need to be updated (buildbot, gump). That should be >> relatively simple. >> >> Docs will need to be updated (relatively simple). >> >> Committers and contributors will rebase any local branches to $new_branch >> >> Having thought about what is involved, renaming the default branch >> doesn't look as problematic as I thought it might be. This looks like >> something that could be done in around an hour for all our repos. >> >> Thoughts? >> > > I, personally, do not see any relation between technical nomenclature and > social problems in real life. > I have many colored skin friends and colleagues and I've never heard > anyone making such associations. > I am Bulgarian. Until not so long ago we were ruled for 5 centuries by > Ottomans but I do not feel like a slave and I don't find 'master' branch > name anyhow related to slavery. > I am -0 on such change and any other change that comes from politics. > > But if we are going to change the branch name then I suggest '10.0.x'. > This way it will be consistent with all other branches. > > Martin > > >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
Re: Changing the name of the default branch in our git repos
Hi, On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas wrote: > All, > > You may have seen the recent discussions both inside and outside the ASF > about the user of "master" as the name of the default git branch. If you > haven't, the short version is that the name can be traced back to > master/slave and its associations with human slavery. > > I'd like to propose that the Apache Tomcat project renames the master > branch in all of the project repositories. > > I think there are two front runners for the new name: > > - main - this looks to be the name GitHub and a number of OSS projects > will be switching to > > - trunk - reflects the Subversion heritage of both the project and the > ASF > > Other options I have seen suggested include "default", "dev", "develop". > Other suggestions welcome. > > Personally, I am leaning towards main as that looks to be the choice of > the majority and using the majority choice will make it (a little bit) > easier for new community members to find their way around the project. > > In terms of impact, changing the name is going to break stuff. It is > really creating a new branch and deleting the old one. > > Deleting a branch triggers the automatic closure of github PRs against > that branch. However if we create "$new_branch" we can edit the PRs to > use "$new_branch" before we delete master. Given the small number of > open PRs that is easily done. > > CI systems will need to be updated (buildbot, gump). That should be > relatively simple. > > Docs will need to be updated (relatively simple). > > Committers and contributors will rebase any local branches to $new_branch > > Having thought about what is involved, renaming the default branch > doesn't look as problematic as I thought it might be. This looks like > something that could be done in around an hour for all our repos. > > Thoughts? > I, personally, do not see any relation between technical nomenclature and social problems in real life. I have many colored skin friends and colleagues and I've never heard anyone making such associations. I am Bulgarian. Until not so long ago we were ruled for 5 centuries by Ottomans but I do not feel like a slave and I don't find 'master' branch name anyhow related to slavery. I am -0 on such change and any other change that comes from politics. But if we are going to change the branch name then I suggest '10.0.x'. This way it will be consistent with all other branches. Martin > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Changing the name of the default branch in our git repos
+1 for main On Tue, Jun 16, 2020 at 8:00 AM Coty Sutherland wrote: > > On Tue, Jun 16, 2020 at 4:02 AM Mark Thomas wrote: > >> All, >> >> You may have seen the recent discussions both inside and outside the ASF >> about the user of "master" as the name of the default git branch. If you >> haven't, the short version is that the name can be traced back to >> master/slave and its associations with human slavery. >> >> I'd like to propose that the Apache Tomcat project renames the master >> branch in all of the project repositories. >> >> I think there are two front runners for the new name: >> >> - main - this looks to be the name GitHub and a number of OSS projects >> will be switching to >> >> - trunk - reflects the Subversion heritage of both the project and the >> ASF >> >> Other options I have seen suggested include "default", "dev", "develop". >> Other suggestions welcome. >> >> Personally, I am leaning towards main as that looks to be the choice of >> the majority and using the majority choice will make it (a little bit) >> easier for new community members to find their way around the project. >> >> In terms of impact, changing the name is going to break stuff. It is >> really creating a new branch and deleting the old one. >> >> Deleting a branch triggers the automatic closure of github PRs against >> that branch. However if we create "$new_branch" we can edit the PRs to >> use "$new_branch" before we delete master. Given the small number of >> open PRs that is easily done. >> >> CI systems will need to be updated (buildbot, gump). That should be >> relatively simple. >> >> Docs will need to be updated (relatively simple). >> >> Committers and contributors will rebase any local branches to $new_branch >> >> Having thought about what is involved, renaming the default branch >> doesn't look as problematic as I thought it might be. This looks like >> something that could be done in around an hour for all our repos. >> >> Thoughts? >> > > I'm +1 for main > > >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Changing the name of the default branch in our git repos
On Tue, Jun 16, 2020 at 4:02 AM Mark Thomas wrote: > All, > > You may have seen the recent discussions both inside and outside the ASF > about the user of "master" as the name of the default git branch. If you > haven't, the short version is that the name can be traced back to > master/slave and its associations with human slavery. > > I'd like to propose that the Apache Tomcat project renames the master > branch in all of the project repositories. > > I think there are two front runners for the new name: > > - main - this looks to be the name GitHub and a number of OSS projects > will be switching to > > - trunk - reflects the Subversion heritage of both the project and the > ASF > > Other options I have seen suggested include "default", "dev", "develop". > Other suggestions welcome. > > Personally, I am leaning towards main as that looks to be the choice of > the majority and using the majority choice will make it (a little bit) > easier for new community members to find their way around the project. > > In terms of impact, changing the name is going to break stuff. It is > really creating a new branch and deleting the old one. > > Deleting a branch triggers the automatic closure of github PRs against > that branch. However if we create "$new_branch" we can edit the PRs to > use "$new_branch" before we delete master. Given the small number of > open PRs that is easily done. > > CI systems will need to be updated (buildbot, gump). That should be > relatively simple. > > Docs will need to be updated (relatively simple). > > Committers and contributors will rebase any local branches to $new_branch > > Having thought about what is involved, renaming the default branch > doesn't look as problematic as I thought it might be. This looks like > something that could be done in around an hour for all our repos. > > Thoughts? > I'm +1 for main > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Changing the name of the default branch in our git repos
Am 2020-06-16 um 12:09 schrieb Mark Thomas: On 16/06/2020 10:25, Michael Osipov wrote: Am 2020-06-16 um 10:02 schrieb Mark Thomas: All, You may have seen the recent discussions both inside and outside the ASF about the user of "master" as the name of the default git branch. If you haven't, the short version is that the name can be traced back to master/slave and its associations with human slavery. I'd like to propose that the Apache Tomcat project renames the master branch in all of the project repositories. I think there are two front runners for the new name: - main - this looks to be the name GitHub and a number of OSS projects will be switching to - trunk - reflects the Subversion heritage of both the project and the ASF Other options I have seen suggested include "default", "dev", "develop". Other suggestions welcome. Personally, I am leaning towards main as that looks to be the choice of the majority and using the majority choice will make it (a little bit) easier for new community members to find their way around the project. In terms of impact, changing the name is going to break stuff. It is really creating a new branch and deleting the old one. Deleting a branch triggers the automatic closure of github PRs against that branch. However if we create "$new_branch" we can edit the PRs to use "$new_branch" before we delete master. Given the small number of open PRs that is easily done. CI systems will need to be updated (buildbot, gump). That should be relatively simple. Docs will need to be updated (relatively simple). Committers and contributors will rebase any local branches to $new_branch Having thought about what is involved, renaming the default branch doesn't look as problematic as I thought it might be. This looks like something that could be done in around an hour for all our repos. Thoughts? Although on the Git ML this has been discussed that master comes from Master Copy (music, recoding, etc) and is not related to slavery, I prefer the term "main" as many other projects now do. It isn't that clear cut. If you trace it back there are places where branches are referred to as master and slave as well as places where the master record idea is used. Various references can be found in this thread: https://twitter.com/tobie/status/1270290278029631489 Indeed, this one is the worst: https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L290-L291 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
On 16/06/2020 10:25, Michael Osipov wrote: > Am 2020-06-16 um 10:02 schrieb Mark Thomas: >> All, >> >> You may have seen the recent discussions both inside and outside the ASF >> about the user of "master" as the name of the default git branch. If you >> haven't, the short version is that the name can be traced back to >> master/slave and its associations with human slavery. >> >> I'd like to propose that the Apache Tomcat project renames the master >> branch in all of the project repositories. >> >> I think there are two front runners for the new name: >> >> - main - this looks to be the name GitHub and a number of OSS projects >> will be switching to >> >> - trunk - reflects the Subversion heritage of both the project and the >> ASF >> >> Other options I have seen suggested include "default", "dev", "develop". >> Other suggestions welcome. >> >> Personally, I am leaning towards main as that looks to be the choice of >> the majority and using the majority choice will make it (a little bit) >> easier for new community members to find their way around the project. >> >> In terms of impact, changing the name is going to break stuff. It is >> really creating a new branch and deleting the old one. >> >> Deleting a branch triggers the automatic closure of github PRs against >> that branch. However if we create "$new_branch" we can edit the PRs to >> use "$new_branch" before we delete master. Given the small number of >> open PRs that is easily done. >> >> CI systems will need to be updated (buildbot, gump). That should be >> relatively simple. >> >> Docs will need to be updated (relatively simple). >> >> Committers and contributors will rebase any local branches to $new_branch >> >> Having thought about what is involved, renaming the default branch >> doesn't look as problematic as I thought it might be. This looks like >> something that could be done in around an hour for all our repos. >> >> Thoughts? > > Although on the Git ML this has been discussed that master comes from > Master Copy (music, recoding, etc) and is not related to slavery, I > prefer the term "main" as many other projects now do. It isn't that clear cut. If you trace it back there are places where branches are referred to as master and slave as well as places where the master record idea is used. Various references can be found in this thread: https://twitter.com/tobie/status/1270290278029631489 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Am 2020-06-16 um 10:02 schrieb Mark Thomas: All, You may have seen the recent discussions both inside and outside the ASF about the user of "master" as the name of the default git branch. If you haven't, the short version is that the name can be traced back to master/slave and its associations with human slavery. I'd like to propose that the Apache Tomcat project renames the master branch in all of the project repositories. I think there are two front runners for the new name: - main - this looks to be the name GitHub and a number of OSS projects will be switching to - trunk - reflects the Subversion heritage of both the project and the ASF Other options I have seen suggested include "default", "dev", "develop". Other suggestions welcome. Personally, I am leaning towards main as that looks to be the choice of the majority and using the majority choice will make it (a little bit) easier for new community members to find their way around the project. In terms of impact, changing the name is going to break stuff. It is really creating a new branch and deleting the old one. Deleting a branch triggers the automatic closure of github PRs against that branch. However if we create "$new_branch" we can edit the PRs to use "$new_branch" before we delete master. Given the small number of open PRs that is easily done. CI systems will need to be updated (buildbot, gump). That should be relatively simple. Docs will need to be updated (relatively simple). Committers and contributors will rebase any local branches to $new_branch Having thought about what is involved, renaming the default branch doesn't look as problematic as I thought it might be. This looks like something that could be done in around an hour for all our repos. Thoughts? Although on the Git ML this has been discussed that master comes from Master Copy (music, recoding, etc) and is not related to slavery, I prefer the term "main" as many other projects now do. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
На вт, 16.06.2020 г. в 11:02 Mark Thomas написа: > > All, > > You may have seen the recent discussions both inside and outside the ASF > about the user of "master" as the name of the default git branch. If you > haven't, the short version is that the name can be traced back to > master/slave and its associations with human slavery. > > I'd like to propose that the Apache Tomcat project renames the master > branch in all of the project repositories. > > I think there are two front runners for the new name: > > - main - this looks to be the name GitHub and a number of OSS projects > will be switching to > > - trunk - reflects the Subversion heritage of both the project and the > ASF > > Other options I have seen suggested include "default", "dev", "develop". > Other suggestions welcome. > > Personally, I am leaning towards main as that looks to be the choice of > the majority and using the majority choice will make it (a little bit) > easier for new community members to find their way around the project. > > In terms of impact, changing the name is going to break stuff. It is > really creating a new branch and deleting the old one. > > Deleting a branch triggers the automatic closure of github PRs against > that branch. However if we create "$new_branch" we can edit the PRs to > use "$new_branch" before we delete master. Given the small number of > open PRs that is easily done. > > CI systems will need to be updated (buildbot, gump). That should be > relatively simple. > > Docs will need to be updated (relatively simple). > > Committers and contributors will rebase any local branches to $new_branch > > Having thought about what is involved, renaming the default branch > doesn't look as problematic as I thought it might be. This looks like > something that could be done in around an hour for all our repos. > > Thoughts? This may help for the gradual migration https://github.com/chancancode/branch-rename/#gradual-migration Regards, Violeta
Changing the name of the default branch in our git repos
All, You may have seen the recent discussions both inside and outside the ASF about the user of "master" as the name of the default git branch. If you haven't, the short version is that the name can be traced back to master/slave and its associations with human slavery. I'd like to propose that the Apache Tomcat project renames the master branch in all of the project repositories. I think there are two front runners for the new name: - main - this looks to be the name GitHub and a number of OSS projects will be switching to - trunk - reflects the Subversion heritage of both the project and the ASF Other options I have seen suggested include "default", "dev", "develop". Other suggestions welcome. Personally, I am leaning towards main as that looks to be the choice of the majority and using the majority choice will make it (a little bit) easier for new community members to find their way around the project. In terms of impact, changing the name is going to break stuff. It is really creating a new branch and deleting the old one. Deleting a branch triggers the automatic closure of github PRs against that branch. However if we create "$new_branch" we can edit the PRs to use "$new_branch" before we delete master. Given the small number of open PRs that is easily done. CI systems will need to be updated (buildbot, gump). That should be relatively simple. Docs will need to be updated (relatively simple). Committers and contributors will rebase any local branches to $new_branch Having thought about what is involved, renaming the default branch doesn't look as problematic as I thought it might be. This looks like something that could be done in around an hour for all our repos. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] branch master updated: Drop all that beta, rc, release bloatware from jk_version.h. We use git, and release should be as simple as clicking on the webpage
This is an automated email from the ASF dual-hosted git repository. mturk pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git The following commit(s) were added to refs/heads/master by this push: new 0ff7479 Drop all that beta,rc,release bloatware from jk_version.h. We use git, and release should be as simple as clicking on the webpage 0ff7479 is described below commit 0ff7479904e1a5447736b020a267b897ff826e1f Author: Mladen Turk AuthorDate: Sat Jun 13 19:07:26 2020 +0200 Drop all that beta,rc,release bloatware from jk_version.h. We use git, and release should be as simple as clicking on the webpage --- native/apache-2.0/Makefile.vc | 2 +- native/common/jk.rc | 35 + native/common/jk_version.h| 52 --- native/iis/Makefile.vc| 2 +- 4 files changed, 31 insertions(+), 60 deletions(-) diff --git a/native/apache-2.0/Makefile.vc b/native/apache-2.0/Makefile.vc index 13d6980..e3d5bbe 100644 --- a/native/apache-2.0/Makefile.vc +++ b/native/apache-2.0/Makefile.vc @@ -105,7 +105,7 @@ $(WORKDIR) : $(CC) $(CLOPTS) $(CFLAGS) $(INCDIR) $(PDBFLAGS) $< $(BUILDRES): ..\common\jk.rc - $(RC) /l 0x409 /i ..\common /d NDEBUG /fo $(BUILDRES) $@ + $(RC) /l 0x409 /n /i ..\common /d NDEBUG /fo $(BUILDRES) ..\common\jk.rc $(BUILDBIN): $(WORKDIR) $(OBJECTS) $(BUILDRES) $(LINK) $(LFLAGS) $(OBJECTS) $(BUILDRES) $(LDLIBS) /out:$(BUILDBIN) /pdb:$(BUILDPDB) diff --git a/native/common/jk.rc b/native/common/jk.rc index e0eae36..a51a385 100644 --- a/native/common/jk.rc +++ b/native/common/jk.rc @@ -39,31 +39,27 @@ 1 VERSIONINFO - FILEVERSION JK_VERSIONCSV - PRODUCTVERSION JK_VERSIONCSV - FILEFLAGSMASK 0x3fL -#if defined(_DEBUG) - FILEFLAGS 0x01L -#else - FILEFLAGS 0x00L -#endif - FILEOS 0x40004L - FILETYPE 0x1L + FILEVERSION JK_VERSIONCSV,0 + PRODUCTVERSION JK_VERSIONCSV,0 + FILEFLAGSMASK VS_FFI_FILEFLAGSMASK + FILEFLAGS 0x0L + FILEOS VOS_NT_WINDOWS32 + FILETYPE VFT_APP FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN -VALUE "Comments", ASF_LICENSE "\0" - VALUE "CompanyName", "Apache Software Foundation\0" - VALUE "FileDescription", "Apache Tomcat Connector\0" - VALUE "FileVersion", JK_VERSTRING "\0" - VALUE "InternalName", PACKAGE "\0" - VALUE "LegalCopyright", ASF_COPYRIGHT "\0" - VALUE "OriginalFilename", PACKAGE "." JK_DLL_SUFFIX "\0" - VALUE "ProductName", "Apache Tomcat " PACKAGE " Connector\0" - VALUE "ProductVersion", JK_VERSTRING "\0" + VALUE "Comments", ASF_LICENSE + VALUE "CompanyName", "Apache Software Foundation" + VALUE "FileDescription", "Apache Tomcat Connector" + VALUE "FileVersion", JK_VERSTRING + VALUE "InternalName", JK_DISTNAME + VALUE "LegalCopyright", ASF_COPYRIGHT + VALUE "OriginalFilename", JK_DISTNAME "." JK_DLL_SUFFIX + VALUE "ProductName", "Apache Tomcat " JK_DISTNAME " Connector" + VALUE "ProductVersion", JK_EXPOSED_VERSION END END BLOCK "VarFileInfo" @@ -71,4 +67,3 @@ BEGIN VALUE "Translation", 0x409, 1200 END END - diff --git a/native/common/jk_version.h b/native/common/jk_version.h index 8ac54cd..a4d06f0 100644 --- a/native/common/jk_version.h +++ b/native/common/jk_version.h @@ -22,57 +22,34 @@ #ifndef __JK_VERSION_H #define __JK_VERSION_H -/** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 49 +#define JK_VERMICRO 49 -/* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 0 -/* Beta number */ -#define JK_VERBETA 0 -#define JK_BETASTRING "0" -/* Release candidate */ -#define JK_VERRC0 -#define JK_RCSTRING "0" - -/** END OF AREA TO MODIFY BEFORE RELEASING */ - -#if !defined(PACKAGE) #if defined(JK_ISAPI) -#define PACKAGE "isapi_redirector" +#define JK_DISTNAME "isapi_redirector" #define JK_DLL_SUFFIX "dll" #elif defined(JK_NSAPI) -#define PACKAGE "nsapi_redirector" +#define JK_DISTNAME "nsapi_redirector" #define JK_DLL_SUFFIX "dll" #else -#define PACKAGE "mod_jk" +#define JK_DISTNAME "mod_jk" #define JK_DLL_SUFFIX "so" #endif -#endif /* Build JK_EXPOSED_VERSION and JK_VERSION */ -#define JK_EXPOSED_VERSION_INT PACKAGE "/" JK_VERSTRING +#define JK_EXP
Re: git-fu is (still) weak
Hi Chris, On Tue, Apr 28, 2020 at 5:58 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Coty, > > On 4/28/20 10:45, Coty Sutherland wrote: > > > > > > On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz > > > <mailto:ch...@christopherschultz.net>> > wrote: > > > > Rémy, > > > > On 4/27/20 18:41, Rémy Maucherat wrote: > >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz > >> >> <mailto:ch...@christopherschultz.net> > >> <mailto:ch...@christopherschultz.net > > <mailto:ch...@christopherschultz.net>>> wrote: > > > >> All, > > > >> I tried again to commit to tc10 branch, got commit id > >> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > > > >> Moving to tc9 branch: > > > >> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > >> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > > >> - From tc10: > > > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) > >> origin https://github.com/apache/tomcat (push) > > > >> - From tc9.0.x: > > > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) > >> origin https://github.com/apache/tomcat (push) > > > >> My 9.0.x local is all up-to-date with github, and github can see > >> the commit in tc10. > > > >> Other than manually handing the diffs myself, I have no idea > >> what to do, next. :( > > > > > >>> I tried and it looked "ok" to me. > > > > Okay, what did you do? When I try to cherry-pick from 10 -> 9 I > > still get the "bad object" error. > > > > When cherry-picking your commits from 9.0.x -> 8.5.x, I get a > > merge-conflict (of course) because you have already merged them. > > > > Did I do something weird with the first commit? > > > > Maybe I don't have my branches in order? > > > > - From my tomcat-trunk (10) directory: > > > > $ git branch -a 9.0.x * master remotes/origin/7.0.x > > remotes/origin/8.5.x remotes/origin/9.0.x > > remotes/origin/BZ-63636/tomcat-8.5.x > > remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x > > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x > > remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master > > remotes/origin/master > > > > - From my tomcat-9.0.x directory: > > > > $ git branch -a * 9.0.x master remotes/origin/9.0.x > > > > - From my tomcat-8.5.x directory: > > > > $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x > > remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x > > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x > > remotes/origin/HEAD -> origin/master remotes/origin/master > > > > My 9.0.x checkout seems "light". > > > > > >> Have you tried a `git fetch origin master` from your 9.0 dir? > >> That'll update the gitdb with new objects and refs from master, > >> which should include the one you're trying to pick. That's the > >> only thing I can think of given that you know your object ID is > >> correct and present in master on upstream :) > > That got 'er goin'! > > It definitely fetched a bunch of stuff, but no new files, etc. > (because becasue I was "up-to-date"). How can I be "up-to-date" > without being "up-to-date"? :( > I see these options for you: 1) don't use several directories for the different branches. Use just one and switch between branches: git checkout master / git checkout 9.0.x / git checkout 8.5.x 2) use https://git-scm.com/docs/git-worktree if you prefer to have separate folder for each branch > > Maybe now I can go back and merge the original commits from this > thread from February. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oRIAACgkQHPApP6U8 > pFhtsA/9HHIvXZSbOsJuiBSkc0mBLonbtnvu5SOGizvcHZwPymfQgv+SC4yxiam+ > oAXEcBOfXnFG+bdBeD80F16xQOXDOT1ndSwMASA2LzdG2iDqSVVD2DvoqX3Sna3N > +5Rp40GpIpctVLaz6rp/xTey9pZhFGy+qAjV6lssykU2Dm0trh8JNsWW4qd5Dd14 > RjLSVPN3fmxJ71hXJ3s5X8AufJmxi/TnMfC5h883WpyCM6Wsd1S7E4joXLPXt3LT > qt82OBCpG23TIAM3CWeBykuKtbpnQ7eSmvMUPiBf8mG/6YoiBoGwuswsZPpDnLj6 > 6j4ni9IjSbPbbt7n5DBFa+QDZ6huIWH5iKcrX27ytQxVDHgDK5J9evHaTK9DbdqW > xdFdpJ5q2swC+EhZmzz524jQWWcXsUIR0kABtT8MRlW33/5Q23m9ImBu9u58Ep+m > vGmg8wCezCXAybCYQ86yjVICIINCd4GErrqh5KPbzMfOmTrvi0CTiqiJl9bsLdXr > MpgbLlKzuaOswFVeI/KbfkKquWZedQVB9Ult2fDNtpRPuqxpjeyJAgu4gTtuwXy4 > +Mr+YFO9zaS49wxBo92L7ZqVn2tYPiMdzxj+39xMKwt5lj+76gq9Iyn7leKxrEZM > skqHJql7EgIwZ+xTVPlAdtERvbq6FkBHAnJxqAYDydkTVSC7CKY= > =9c6q > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: git-fu is (still) weak
On Tue, Apr 28, 2020 at 10:58 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Coty, > > On 4/28/20 10:45, Coty Sutherland wrote: > > > > > > On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz > > > <mailto:ch...@christopherschultz.net>> > wrote: > > > > Rémy, > > > > On 4/27/20 18:41, Rémy Maucherat wrote: > >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz > >> >> <mailto:ch...@christopherschultz.net> > >> <mailto:ch...@christopherschultz.net > > <mailto:ch...@christopherschultz.net>>> wrote: > > > >> All, > > > >> I tried again to commit to tc10 branch, got commit id > >> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > > > >> Moving to tc9 branch: > > > >> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > >> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > > >> - From tc10: > > > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) > >> origin https://github.com/apache/tomcat (push) > > > >> - From tc9.0.x: > > > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) > >> origin https://github.com/apache/tomcat (push) > > > >> My 9.0.x local is all up-to-date with github, and github can see > >> the commit in tc10. > > > >> Other than manually handing the diffs myself, I have no idea > >> what to do, next. :( > > > > > >>> I tried and it looked "ok" to me. > > > > Okay, what did you do? When I try to cherry-pick from 10 -> 9 I > > still get the "bad object" error. > > > > When cherry-picking your commits from 9.0.x -> 8.5.x, I get a > > merge-conflict (of course) because you have already merged them. > > > > Did I do something weird with the first commit? > > > > Maybe I don't have my branches in order? > > > > - From my tomcat-trunk (10) directory: > > > > $ git branch -a 9.0.x * master remotes/origin/7.0.x > > remotes/origin/8.5.x remotes/origin/9.0.x > > remotes/origin/BZ-63636/tomcat-8.5.x > > remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x > > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x > > remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master > > remotes/origin/master > > > > - From my tomcat-9.0.x directory: > > > > $ git branch -a * 9.0.x master remotes/origin/9.0.x > > > > - From my tomcat-8.5.x directory: > > > > $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x > > remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x > > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x > > remotes/origin/HEAD -> origin/master remotes/origin/master > > > > My 9.0.x checkout seems "light". > > > > > >> Have you tried a `git fetch origin master` from your 9.0 dir? > >> That'll update the gitdb with new objects and refs from master, > >> which should include the one you're trying to pick. That's the > >> only thing I can think of given that you know your object ID is > >> correct and present in master on upstream :) > > That got 'er goin'! > Woo! \o/ I'm glad that worked. > It definitely fetched a bunch of stuff, but no new files, etc. > (because becasue I was "up-to-date"). How can I be "up-to-date" > without being "up-to-date"? :( > You were doing a `git pull` (derived from your note about being "Already up to date"), which was only fetching and merging the current branch when you needed to fetch object/refs from a different branch and then pick one of those commits from that branch. Since it was only doing the current branch, you are technically "up to date". If you tried to `git pull origin master` then that would fetch all the objects/refs from master while also merging (bring the new files down) which is not what you want :) Using `git fetch` is the best way to get up to date references without actually updating the code base you're working with. HTH > Maybe now I can go back and merge the original commits from this > thread from February. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oRIAACgkQHPApP6U8 > pFhtsA/9HHIvXZSbOsJuiBSkc0mBLonbtnvu5SOGizvcHZwPymfQgv+SC4yxiam+ > oAXEcBOfXnFG+bdBeD80F16xQOXDOT1nd
Re: git-fu is (still) weak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Coty, On 4/28/20 10:45, Coty Sutherland wrote: > > > On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz > <mailto:ch...@christopherschultz.net>> wrote: > > Rémy, > > On 4/27/20 18:41, Rémy Maucherat wrote: >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz >> > <mailto:ch...@christopherschultz.net> >> <mailto:ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>>> wrote: > >> All, > >> I tried again to commit to tc10 branch, got commit id >> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > >> Moving to tc9 branch: > >> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf >> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > >> - From tc10: > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) >> origin https://github.com/apache/tomcat (push) > >> - From tc9.0.x: > >> $ git remote -v origin https://github.com/apache/tomcat (fetch) >> origin https://github.com/apache/tomcat (push) > >> My 9.0.x local is all up-to-date with github, and github can see >> the commit in tc10. > >> Other than manually handing the diffs myself, I have no idea >> what to do, next. :( > > >>> I tried and it looked "ok" to me. > > Okay, what did you do? When I try to cherry-pick from 10 -> 9 I > still get the "bad object" error. > > When cherry-picking your commits from 9.0.x -> 8.5.x, I get a > merge-conflict (of course) because you have already merged them. > > Did I do something weird with the first commit? > > Maybe I don't have my branches in order? > > - From my tomcat-trunk (10) directory: > > $ git branch -a 9.0.x * master remotes/origin/7.0.x > remotes/origin/8.5.x remotes/origin/9.0.x > remotes/origin/BZ-63636/tomcat-8.5.x > remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x > remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master > remotes/origin/master > > - From my tomcat-9.0.x directory: > > $ git branch -a * 9.0.x master remotes/origin/9.0.x > > - From my tomcat-8.5.x directory: > > $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x > remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x > remotes/origin/HEAD -> origin/master remotes/origin/master > > My 9.0.x checkout seems "light". > > >> Have you tried a `git fetch origin master` from your 9.0 dir? >> That'll update the gitdb with new objects and refs from master, >> which should include the one you're trying to pick. That's the >> only thing I can think of given that you know your object ID is >> correct and present in master on upstream :) That got 'er goin'! It definitely fetched a bunch of stuff, but no new files, etc. (because becasue I was "up-to-date"). How can I be "up-to-date" without being "up-to-date"? :( Maybe now I can go back and merge the original commits from this thread from February. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oRIAACgkQHPApP6U8 pFhtsA/9HHIvXZSbOsJuiBSkc0mBLonbtnvu5SOGizvcHZwPymfQgv+SC4yxiam+ oAXEcBOfXnFG+bdBeD80F16xQOXDOT1ndSwMASA2LzdG2iDqSVVD2DvoqX3Sna3N +5Rp40GpIpctVLaz6rp/xTey9pZhFGy+qAjV6lssykU2Dm0trh8JNsWW4qd5Dd14 RjLSVPN3fmxJ71hXJ3s5X8AufJmxi/TnMfC5h883WpyCM6Wsd1S7E4joXLPXt3LT qt82OBCpG23TIAM3CWeBykuKtbpnQ7eSmvMUPiBf8mG/6YoiBoGwuswsZPpDnLj6 6j4ni9IjSbPbbt7n5DBFa+QDZ6huIWH5iKcrX27ytQxVDHgDK5J9evHaTK9DbdqW xdFdpJ5q2swC+EhZmzz524jQWWcXsUIR0kABtT8MRlW33/5Q23m9ImBu9u58Ep+m vGmg8wCezCXAybCYQ86yjVICIINCd4GErrqh5KPbzMfOmTrvi0CTiqiJl9bsLdXr MpgbLlKzuaOswFVeI/KbfkKquWZedQVB9Ult2fDNtpRPuqxpjeyJAgu4gTtuwXy4 +Mr+YFO9zaS49wxBo92L7ZqVn2tYPiMdzxj+39xMKwt5lj+76gq9Iyn7leKxrEZM skqHJql7EgIwZ+xTVPlAdtERvbq6FkBHAnJxqAYDydkTVSC7CKY= =9c6q -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is (still) weak
On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Rémy, > > On 4/27/20 18:41, Rémy Maucherat wrote: > > On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz > > > <mailto:ch...@christopherschultz.net>> > wrote: > > > > All, > > > > I tried again to commit to tc10 branch, got commit id > > 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > > > > Moving to tc9 branch: > > > > $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > > > - From tc10: > > > > $ git remote -v origin https://github.com/apache/tomcat (fetch) > > origin https://github.com/apache/tomcat (push) > > > > - From tc9.0.x: > > > > $ git remote -v origin https://github.com/apache/tomcat (fetch) > > origin https://github.com/apache/tomcat (push) > > > > My 9.0.x local is all up-to-date with github, and github can see > > the commit in tc10. > > > > Other than manually handing the diffs myself, I have no idea what > > to do, next. :( > > > > > >> I tried and it looked "ok" to me. > > Okay, what did you do? When I try to cherry-pick from 10 -> 9 I still > get the "bad object" error. > > When cherry-picking your commits from 9.0.x -> 8.5.x, I get a > merge-conflict (of course) because you have already merged them. > > Did I do something weird with the first commit? > > Maybe I don't have my branches in order? > > - From my tomcat-trunk (10) directory: > > $ git branch -a > 9.0.x > * master > remotes/origin/7.0.x > remotes/origin/8.5.x > remotes/origin/9.0.x > remotes/origin/BZ-63636/tomcat-8.5.x > remotes/origin/BZ-63636/tomcat-9.0.x > remotes/origin/BZ-63681/8.5.x > remotes/origin/BZ-63681/9.0.x > remotes/origin/BZ-63835/8.5.x > remotes/origin/BZ-63835/9.0.x > remotes/origin/HEAD -> origin/master > remotes/origin/master > > - From my tomcat-9.0.x directory: > > $ git branch -a > * 9.0.x > master > remotes/origin/9.0.x > > - From my tomcat-8.5.x directory: > > $ git branch -a > * 8.5.x > remotes/origin/7.0.x > remotes/origin/8.5.x > remotes/origin/9.0.x > remotes/origin/BZ-63681/8.5.x > remotes/origin/BZ-63681/9.0.x > remotes/origin/BZ-63835/9.0.x > remotes/origin/HEAD -> origin/master > remotes/origin/master > > My 9.0.x checkout seems "light". > Have you tried a `git fetch origin master` from your 9.0 dir? That'll update the gitdb with new objects and refs from master, which should include the one you're trying to pick. That's the only thing I can think of given that you know your object ID is correct and present in master on upstream :) > Thanks, > - -chris > > > On 2/24/20 11:33, Christopher Schultz wrote: > >> All, > > > >> I'm trying to cherry-pick a commit. The commit went through > >> github, merged a PR from a contributor into master. I'm trying > >> to cherry-pick it back into the 9.0.x branch: > > > >> $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f > >> error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge > >> but no -m option was given. fatal: cherry-pick failed > > > >> ?? > > > >> My local copy is all up-to-date, no weird local changes or > >> anything like that. What is a "merge", here? Supplying "-m" > >> doesn't like the commit id. > > > >> Any ideas? > > > >> -chris > > > > > > > - - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > <mailto:dev-unsubscr...@tomcat.apache.org> For additional commands, > > e-mail: dev-h...@tomcat.apache.org > > <mailto:dev-h...@tomcat.apache.org> > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oO7kACgkQHPApP6U8 > pFgZTg//WzVb7BJyj9EKcwMm/k+tlNyZqGCH8uTMhntjFkUb9aHHLT/9PhMdBizS > bu4dIB8MtqwxSFv+jrMypccHyRGSx8OFI8Ti0BIC42whhz8AW8BLJ2JSWZrGv+lL > cHPxoosd/dFA4Ft4Acj8GG2WFeG9IUrf+vBbYC2y3jp8oRIvWFSFZQzG0Slt9Rv4 > J4NUIZHkuGGQP88cey1UOw/09T/4wtTm0mFcmyjnVrXDHjrXG3CkMiwU3fo/FOyj > GmpYDEZXgVgDtUgLMG3kSynqJ4XUbRCEJJQ2nEpphFRA+qa9julCRU/D+NdLw9Ya > 7MOWDWFiE7oRsUyU0qgK/GhMw0mQpmXrJuAQLyM2LaaUJ1ZZ5mr/Xqw1cuWJOYCW > TZqNXhyki8XKJSxkNlBSIMouafeX3prX8A2m8erPy83RJx5d7/T1uZNHO86Vd7Qh > ijFbAdyuICcZUPjgF/TK3AHQCVZpqQZHd/oyEVpWwdM7okhVVjoMI+WXft16oQO/ > B468o8llMLE7vTAxzB9dCSOw9wpqoaPTtkd9fH20xPGWTWii0Hkk4WrWDwoUtWbO > xdFgCLQAd2fgVnwuSpOD5c2GeJoKD/Fc4D/JkJo5+bWVKJ7es2kCnT3xBVbDQj0T > Tx2HJ+B0OmCKP5df6f7SYDVxtVJ15J+BgXK5msJpIZumkassfN0= > =bp2k > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: git-fu is (still) weak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 4/27/20 18:41, Rémy Maucherat wrote: > On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz > <mailto:ch...@christopherschultz.net>> wrote: > > All, > > I tried again to commit to tc10 branch, got commit id > 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > > Moving to tc9 branch: > > $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > - From tc10: > > $ git remote -v origin https://github.com/apache/tomcat (fetch) > origin https://github.com/apache/tomcat (push) > > - From tc9.0.x: > > $ git remote -v origin https://github.com/apache/tomcat (fetch) > origin https://github.com/apache/tomcat (push) > > My 9.0.x local is all up-to-date with github, and github can see > the commit in tc10. > > Other than manually handing the diffs myself, I have no idea what > to do, next. :( > > >> I tried and it looked "ok" to me. Okay, what did you do? When I try to cherry-pick from 10 -> 9 I still get the "bad object" error. When cherry-picking your commits from 9.0.x -> 8.5.x, I get a merge-conflict (of course) because you have already merged them. Did I do something weird with the first commit? Maybe I don't have my branches in order? - From my tomcat-trunk (10) directory: $ git branch -a 9.0.x * master remotes/origin/7.0.x remotes/origin/8.5.x remotes/origin/9.0.x remotes/origin/BZ-63636/tomcat-8.5.x remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master remotes/origin/master - From my tomcat-9.0.x directory: $ git branch -a * 9.0.x master remotes/origin/9.0.x - From my tomcat-8.5.x directory: $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master remotes/origin/master My 9.0.x checkout seems "light". Thanks, - -chris > On 2/24/20 11:33, Christopher Schultz wrote: >> All, > >> I'm trying to cherry-pick a commit. The commit went through >> github, merged a PR from a contributor into master. I'm trying >> to cherry-pick it back into the 9.0.x branch: > >> $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f >> error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge >> but no -m option was given. fatal: cherry-pick failed > >> ?? > >> My local copy is all up-to-date, no weird local changes or >> anything like that. What is a "merge", here? Supplying "-m" >> doesn't like the commit id. > >> Any ideas? > >> -chris > > > - - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org> For additional commands, > e-mail: dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oO7kACgkQHPApP6U8 pFgZTg//WzVb7BJyj9EKcwMm/k+tlNyZqGCH8uTMhntjFkUb9aHHLT/9PhMdBizS bu4dIB8MtqwxSFv+jrMypccHyRGSx8OFI8Ti0BIC42whhz8AW8BLJ2JSWZrGv+lL cHPxoosd/dFA4Ft4Acj8GG2WFeG9IUrf+vBbYC2y3jp8oRIvWFSFZQzG0Slt9Rv4 J4NUIZHkuGGQP88cey1UOw/09T/4wtTm0mFcmyjnVrXDHjrXG3CkMiwU3fo/FOyj GmpYDEZXgVgDtUgLMG3kSynqJ4XUbRCEJJQ2nEpphFRA+qa9julCRU/D+NdLw9Ya 7MOWDWFiE7oRsUyU0qgK/GhMw0mQpmXrJuAQLyM2LaaUJ1ZZ5mr/Xqw1cuWJOYCW TZqNXhyki8XKJSxkNlBSIMouafeX3prX8A2m8erPy83RJx5d7/T1uZNHO86Vd7Qh ijFbAdyuICcZUPjgF/TK3AHQCVZpqQZHd/oyEVpWwdM7okhVVjoMI+WXft16oQO/ B468o8llMLE7vTAxzB9dCSOw9wpqoaPTtkd9fH20xPGWTWii0Hkk4WrWDwoUtWbO xdFgCLQAd2fgVnwuSpOD5c2GeJoKD/Fc4D/JkJo5+bWVKJ7es2kCnT3xBVbDQj0T Tx2HJ+B0OmCKP5df6f7SYDVxtVJ15J+BgXK5msJpIZumkassfN0= =bp2k -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is (still) weak
On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > I tried again to commit to tc10 branch, got commit id > 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. > > Moving to tc9 branch: > > $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf > > - From tc10: > > $ git remote -v > origin https://github.com/apache/tomcat (fetch) > origin https://github.com/apache/tomcat (push) > > - From tc9.0.x: > > $ git remote -v > origin https://github.com/apache/tomcat (fetch) > origin https://github.com/apache/tomcat (push) > > My 9.0.x local is all up-to-date with github, and github can see the > commit in tc10. > > Other than manually handing the diffs myself, I have no idea what to > do, next. :( > I tried and it looked "ok" to me. Rémy > > - -chris > > On 2/24/20 11:33, Christopher Schultz wrote: > > All, > > > > I'm trying to cherry-pick a commit. The commit went through > > github, merged a PR from a contributor into master. I'm trying to > > cherry-pick it back into the 9.0.x branch: > > > > $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: > > commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no > > -m option was given. fatal: cherry-pick failed > > > > ?? > > > > My local copy is all up-to-date, no weird local changes or > > anything like that. What is a "merge", here? Supplying "-m" doesn't > > like the commit id. > > > > Any ideas? > > > > -chris > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nWssACgkQHPApP6U8 > pFgE0RAAkCCN0ai+byJh3TGyQRWGP1WTUc92UO7kbVCFiJTe/1s6XtUOwPguiJ87 > rbIAZRsKDefVJVZguad6mXQEkQEnAXQF3w5TvLt8abGbOKi1z4UG+ONwHdptwQfZ > 83vIexa4mV2yw45mpTPqYIZ16eke41x+YV1cZea0iEqp7eQ12HN71je7E0HzEGFN > lDCf+sBHGjBeJ63LSsZ/hIU+LoWgmGBmc0j9GK1UlsL0LhpH6Cz/dXoyqsCxIXl4 > 3BIP5FmSK+3d+f5ciVUrAQJCH6SF0yYEx4+JtUVIUl1lJN5OwvZsyhnHHX4OqiHg > Qp0Zx7h8+mj83MAwZDDyyNcABoF4hyrEMoS9w/I2+zCNrs7RGZGKqvZRIwR2IhCR > rdhfTisc9nkmwZhg+Yt485l0m/IOO/XNqijZ8O4oxUz14BmDHrUoIYlnT3BEKe4q > 7roZpz78JmcCDlFDkEcvaZKJ68vww0CFZsoWXTGDCZuckJQaAOz6Jf9470g2Y79/ > WHtxmBtLNimexrbLN4COYsVoPQbk1X1xGhi2fYqyMNjVGV2cqdOo2I+VAurfRhnh > wpoLzN2mNh0qi23pdyrRsSyRB/KdAszVa2fjIR7WD74AamNy/CzMrydx0b2OpB8k > UbQ/uRuFR7q7jm5N2d0fELMWRPV03RcQ9iIFxtvPE0kGLLvyjm4= > =LDJJ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: git-fu is (still) weak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I tried again to commit to tc10 branch, got commit id 8dddc11512fbd3b91ed9d737a42e4b8415458ddf. Moving to tc9 branch: $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf - From tc10: $ git remote -v origin https://github.com/apache/tomcat (fetch) origin https://github.com/apache/tomcat (push) - From tc9.0.x: $ git remote -v origin https://github.com/apache/tomcat (fetch) origin https://github.com/apache/tomcat (push) My 9.0.x local is all up-to-date with github, and github can see the commit in tc10. Other than manually handing the diffs myself, I have no idea what to do, next. :( - -chris On 2/24/20 11:33, Christopher Schultz wrote: > All, > > I'm trying to cherry-pick a commit. The commit went through > github, merged a PR from a contributor into master. I'm trying to > cherry-pick it back into the 9.0.x branch: > > $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: > commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no > -m option was given. fatal: cherry-pick failed > > ?? > > My local copy is all up-to-date, no weird local changes or > anything like that. What is a "merge", here? Supplying "-m" doesn't > like the commit id. > > Any ideas? > > -chris > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nWssACgkQHPApP6U8 pFgE0RAAkCCN0ai+byJh3TGyQRWGP1WTUc92UO7kbVCFiJTe/1s6XtUOwPguiJ87 rbIAZRsKDefVJVZguad6mXQEkQEnAXQF3w5TvLt8abGbOKi1z4UG+ONwHdptwQfZ 83vIexa4mV2yw45mpTPqYIZ16eke41x+YV1cZea0iEqp7eQ12HN71je7E0HzEGFN lDCf+sBHGjBeJ63LSsZ/hIU+LoWgmGBmc0j9GK1UlsL0LhpH6Cz/dXoyqsCxIXl4 3BIP5FmSK+3d+f5ciVUrAQJCH6SF0yYEx4+JtUVIUl1lJN5OwvZsyhnHHX4OqiHg Qp0Zx7h8+mj83MAwZDDyyNcABoF4hyrEMoS9w/I2+zCNrs7RGZGKqvZRIwR2IhCR rdhfTisc9nkmwZhg+Yt485l0m/IOO/XNqijZ8O4oxUz14BmDHrUoIYlnT3BEKe4q 7roZpz78JmcCDlFDkEcvaZKJ68vww0CFZsoWXTGDCZuckJQaAOz6Jf9470g2Y79/ WHtxmBtLNimexrbLN4COYsVoPQbk1X1xGhi2fYqyMNjVGV2cqdOo2I+VAurfRhnh wpoLzN2mNh0qi23pdyrRsSyRB/KdAszVa2fjIR7WD74AamNy/CzMrydx0b2OpB8k UbQ/uRuFR7q7jm5N2d0fELMWRPV03RcQ9iIFxtvPE0kGLLvyjm4= =LDJJ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Am 2020-02-24 um 21:35 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 2/24/20 14:15, Michael Osipov wrote: Am 2020-02-24 um 17:33 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm trying to cherry-pick a commit. The commit went through github, merged a PR from a contributor into master. I'm trying to cherry-pick it back into the 9.0.x branch: $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no -m option was given. fatal: cherry-pick failed ?? My local copy is all up-to-date, no weird local changes or anything like that. What is a "merge", here? Supplying "-m" doesn't like the commit id. $ git log --graph * commit 900ed3ef96080ec378fea452dcd748bf3bfa0ec0 (HEAD -> master, origin/master, origin/HEAD) | Author: Christopher Schultz | Date: 2020-02-24 17:26:31 +0100 | | Add changelog entry. | * commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f |\ Merge: 03b2af7473 bf2447b4bd | | Author: Christopher Schultz | | Date: 2020-02-24 17:21:31 +0100 | | | | Merge pull request #240 from ThStock/master | | | | Added extension point for custom delta requests | | | * commit bf2447b4bd9edda25e00c7aaab9fcce455c43f2f | | Author: Thomas Stock | | Date: 2020-02-13 12:55:32 +0100 | | | | Added extension point for custom delta requests | | You can't cherry-pick merge commits. WTF is a merge-commit? A merge commit reconciles two or more tree where history has dirverged from each other. Try to avoid merge commits. I clicked "Merge PR" in GitHub. I don't believe I had any choices in the matter. I already assumed so. GitHub is stupid and creates this useless commit. On the right-hand side of that button is a menu button which does rebase and merge. See here: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request In most cases all they do is to add clutter with zero benefit [1]. Single-click to accept a PR is great. I see that is CAN cause (me) problems, but it shouldn't be this hard. It is hard, if you don't know what it is doing it exactly. Rebase the branch you want to merge on top of the targer branch, switch and then merge. I don't control the source's github fork, so that's a no-go. That's not a no go. You mostly have this: Add more commits by pushing to the session-manager-persist-authentication branch on cklein05/tomcat. If you don't, request the PR creator to do the rebase, alternatively use your clone from Gitbox, create a branch and merge the foreign branch. If everything is fine, merge into master. With that, you have full control. This is how we merge PR in Maven. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 2/24/20 14:15, Michael Osipov wrote: > Am 2020-02-24 um 17:33 schrieb Christopher Schultz: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> All, >> >> I'm trying to cherry-pick a commit. The commit went through >> github, merged a PR from a contributor into master. I'm trying to >> cherry-pick it back into the 9.0.x branch: >> >> $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: >> commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no >> -m option was given. fatal: cherry-pick failed >> >> ?? >> >> My local copy is all up-to-date, no weird local changes or >> anything like that. What is a "merge", here? Supplying "-m" >> doesn't like the commit id. > >> $ git log --graph * commit >> 900ed3ef96080ec378fea452dcd748bf3bfa0ec0 (HEAD -> master, >> origin/master, origin/HEAD) | Author: Christopher Schultz >> | Date: 2020-02-24 17:26:31 >> +0100 | | Add changelog entry. | * commit >> f124a9c7230227d3eaff9d2dc1c52f82ce10e03f |\ Merge: 03b2af7473 >> bf2447b4bd | | Author: Christopher Schultz >> | | Date: 2020-02-24 17:21:31 >> +0100 | | | | Merge pull request #240 from ThStock/master | >> | | | Added extension point for custom delta requests | | | * >> commit bf2447b4bd9edda25e00c7aaab9fcce455c43f2f | | Author: >> Thomas Stock | | Date: 2020-02-13 >> 12:55:32 +0100 | | | | Added extension point for custom delta >> requests | | > > You can't cherry-pick merge commits. WTF is a merge-commit? > Try to avoid merge commits. I clicked "Merge PR" in GitHub. I don't believe I had any choices in the matter. > In most cases all they do is to add clutter with zero benefit [1]. Single-click to accept a PR is great. I see that is CAN cause (me) problems, but it shouldn't be this hard. > Rebase the branch you want to merge on top of the targer branch, > switch and then merge. I don't control the source's github fork, so that's a no-go. > This is trivial via shell. Other than clicking "Merge PR" in github, I do everything via CLI. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5UM38ACgkQHPApP6U8 pFiBtw//Yq9O6JwZyECcNZxT+nSaXu8ih1TQd5d9X89PnMEoi/1TX1e/3destk/A FoZr1Q6X/jOr3wnwDEVv6BbWaDwli6lR2swZDjENi2UeyqUTVHPmSV/q5cj5VOjs 5At7HjOA2FPQJ7oEfw7NSqKs20a4qFhtjJ+CfosfrsbQzTe6fBo9uSAgOXxzAsm+ +IZzCv1moj7037ps0UrmBkWEiwb2zRRj7rqtaZS+M/zUr10WItH2Qpb7RphExcdm 2RDbJjNYWHVDUYOjHAVrPEUiw83gxpOnH3dqJwoXqdtDLkbtLA5xNhmxg+o/MWlN 2S5d1739vBrTZFowXS0aGyZNH3rFTqO9jKsv8LIhBBIA2iioGw7gu3tU+OSI0fZR Ad039m48FfjSRtQKO+Ne03+vOBp64grG4B9KaloAhzt86bb/jlsZYf21M4bcwVVW zqjMy6FyUqnWPVYRW0V6f59b/OH3ZcBAjj2MYBF+r6OscrS7m//Tm8aEEysksZbF orBj6n80XNGwn4jJYFW4W4MMVSTED5uUh38irnIiObK7zdIriWeARouktxumOT2d faA6Ozf5ZIXxJdbafbSnOeX+/XnoiupPHpR7/hRhc3aHlz0gbIBHzPIzTi+nYma1 L/s7vmvbjDpZZNzAsUncAwt+H1PxD22Xa5gWN+aSpuijPlIQbnM= =6LUI -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Am 2020-02-24 um 17:33 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm trying to cherry-pick a commit. The commit went through github, merged a PR from a contributor into master. I'm trying to cherry-pick it back into the 9.0.x branch: $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no -m option was given. fatal: cherry-pick failed ?? My local copy is all up-to-date, no weird local changes or anything like that. What is a "merge", here? Supplying "-m" doesn't like the commit id. $ git log --graph * commit 900ed3ef96080ec378fea452dcd748bf3bfa0ec0 (HEAD -> master, origin/master, origin/HEAD) | Author: Christopher Schultz | Date: 2020-02-24 17:26:31 +0100 | | Add changelog entry. | * commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f |\ Merge: 03b2af7473 bf2447b4bd | | Author: Christopher Schultz | | Date: 2020-02-24 17:21:31 +0100 | | | | Merge pull request #240 from ThStock/master | | | | Added extension point for custom delta requests | | | * commit bf2447b4bd9edda25e00c7aaab9fcce455c43f2f | | Author: Thomas Stock | | Date: 2020-02-13 12:55:32 +0100 | | | | Added extension point for custom delta requests | | You can't cherry-pick merge commits. Try to avoid merge commits. In most cases all they do is to add clutter with zero benefit [1]. Rebase the branch you want to merge on top of the targer branch, switch and then merge. This is trivial via shell. [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html?source=techstories.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
пн, 24 февр. 2020 г. в 19:40, Emmanuel Bourg : > > Le 24/02/2020 à 17:33, Christopher Schultz a écrit : > > > Any ideas? > > I guess you are cherry picking the merge commit, instead of the actual > commit(s) from the PR branch. > https://github.com/apache/tomcat/commit/f124a9c7230227d3eaff9d2dc1c52f82ce10e03f says: "2 parents 03b2af7 + bf2447b" I guess that you want this commit: https://github.com/apache/tomcat/commit/bf2447b4bd9edda25e00c7aaab9fcce455c43f2f I am not fluent with command-line for this command, as I usually do it via GUI (provided by TortoiseGit). "git help cherry-pick" may help you. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Le 24/02/2020 à 17:33, Christopher Schultz a écrit : > Any ideas? I guess you are cherry picking the merge commit, instead of the actual commit(s) from the PR branch. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
git-fu is weak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm trying to cherry-pick a commit. The commit went through github, merged a PR from a contributor into master. I'm trying to cherry-pick it back into the 9.0.x branch: $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no -m option was given. fatal: cherry-pick failed ?? My local copy is all up-to-date, no weird local changes or anything like that. What is a "merge", here? Supplying "-m" doesn't like the commit id. Any ideas? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5T+t8ACgkQHPApP6U8 pFjwvRAAnaog8gRDB+vajg0CCXYmCvq24yO5FZNbcQSQCyTLM7WnIfFUCYanI+VG hnSdmWcqyv2P/zHij67EyO+TmrPIqI6WLv5/xOIMHH6JYZK3eebpofwrIAoxJ5je xM1shwvjXYss7LNs5uxVThmWg3z5KGjGX9VuQVtaROx4LvAYWPQ+ajld/KXU5qha R7ytbDD96bgty7iiScaG7cPHYZryq3ePnhphR7nYp1RhHXUkdB//nc2PmS5166MU NZtxbCF28T55wXifJV5ZCodHs2tJh+zu9LeYP9hgUkoAQedJ8fSMk4DnKz+RCFXB huVArT0kuy5t2FoSweNpI9NpzoHRxnleGPsqJv20g9CcVzJqCLisyyLCxP1YUuNI te3rtjKUY0aegTE4DbVpQg49iblnsAJyVhMQIkOhKcciM3P2ZNNOVvuiNhNzPaV+ U/uR9tB8+e0XQX5ONt1Q1L6/u4dYTuXgFRkWU0K4b1eIjfsicECgOq5lcKUlxlIe Jl3rJx8FAZpR6AiHUoJy7tujd6/SIoSOCg9BWmfj8I2pslKpY1nFxfhSF9bhcsr3 fSPcjUZyGpZqjzgxXi2jA2XjJgqaMoyWkscRavLNv9jWKLtUNUPmpNCKPRW07HCc hA9Fvukuq6c7Sjy9y+ZH8in7lbGtdcBYhm8+BQhbJimyLn377DI= =Fx8W -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] 02/03: Git repo name changed
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git commit fd76777a421c18608f069432563db4ea71b45a8b Author: Mark Thomas AuthorDate: Wed Feb 19 11:40:26 2020 + Git repo name changed --- tools/jkrelease.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/jkrelease.sh b/tools/jkrelease.sh index 95a11dd..eca8196 100755 --- a/tools/jkrelease.sh +++ b/tools/jkrelease.sh @@ -27,7 +27,7 @@ # And any one of: w3m, elinks, links (links2) SVN_REPOS="http://svn.apache.org/repos/asf/tomcat/jk; -GIT_REPOS="https://gitbox.apache.org/repos/asf/tomcat-jk.git; +GIT_REPOS="https://gitbox.apache.org/repos/asf/tomcat-connectors.git; JK_CVST="tomcat-connectors" JK_OWNER="root" JK_GROUP="bin" - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] 03/03: Git tags retained svn format (for now)
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git
commit 637edee00ca30b1d927f41d40748809c61ccb70e
Author: Mark Thomas
AuthorDate: Wed Feb 19 11:59:42 2020 +
Git tags retained svn format (for now)
---
tools/jkrelease.sh | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/jkrelease.sh b/tools/jkrelease.sh
index eca8196..fabd5a1 100755
--- a/tools/jkrelease.sh
+++ b/tools/jkrelease.sh
@@ -254,14 +254,17 @@ then
JK_DIST=${JK_CVST}-${version}-dev${JK_SUFFIX}-src
fi
else
+JK_TAG=`echo $version | sed -e 's#^#JK_#' -e 's#\.#_#g'`
if [ $USE_GIT -eq 1 ]
then
+echo Tag:[$tag]
+echo JK_TAG: [$JK_TAG]
if [ -n "$tag" ]
then
if [ -z "$force" ]
then
-echo $tag | grep "^$version" > /dev/null 2>&1
-if [ "X$tag" != "X$version" ]
+echo $tag | grep "^$JK_TAG" > /dev/null 2>&1
+if [ "X$tag" != "X$JK_TAG" ]
then
echo "Tag '$tag' doesn't belong to version '$version'."
echo "Force by using '-f' if you are sure."
@@ -276,17 +279,16 @@ else
fi
JK_SUFFIX=-tag-${tag}-${JK_REV}
else
-JK_REV=`git ls-remote $REPOS refs/tags/$version | awk '{print $1}'`
+JK_REV=`git ls-remote $REPOS refs/tags/$JK_TAG | awk '{print $1}'`
if [ -z "$JK_REV" ]
then
- echo "No git hash found via 'git ls-remote $REPOS
refs/tags/$version'"
+ echo "No git hash found via 'git ls-remote $REPOS
refs/tags/$JK_TAG'"
exit 3
fi
JK_SUFFIX=''
fi
JK_DIST=${JK_CVST}-${version}${JK_SUFFIX}-src
else
-JK_TAG=`echo $version | sed -e 's#^#JK_#' -e 's#\.#_#g'`
if [ -n "$tag" ]
then
if [ -z "$force" ]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] 01/02: svn -> git updates
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git
commit a8a7db6ce26c5d64fe974b9c8bb08681f6381313
Author: Mark Thomas
AuthorDate: Mon Feb 17 15:59:02 2020 +
svn -> git updates
---
HOWTO-RELEASE.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/HOWTO-RELEASE.txt b/HOWTO-RELEASE.txt
index 5a090fe..57fdd2a 100644
--- a/HOWTO-RELEASE.txt
+++ b/HOWTO-RELEASE.txt
@@ -16,9 +16,9 @@
How to do a mod_jk 1.2 Release
==
-Check out a clean copy of tomcat/connectors from subversion to
-make sure you don't have any lingering configure or build files.
-This will make sure that the source distribution created is clean.
+Clone a clean copy of tomcat/connectors from git to make sure you don't have
+any lingering configure or build files. This will make sure that the source
+distribution created is clean.
We assume, that you cloned out g...@github.com:apache/tomcat-connectors.git
to a directory named mod_jk. All further path names will be relative to this
@@ -77,12 +77,12 @@ Index: native/common/jk_version.h
#define JK_VERRC0
#define JK_RCSTRING "0"
-After updating revision numbers, commit your changes to subversion.
+After updating revision numbers, commit your changes to git.
-Tag and branch tomcat-connectors in subversion
---
+Tag tomcat-connectors in git
+
-Use the pattern below for branching and tagging the tomcat-connectors
directory.
+Use the pattern below for tagging the tomcat-connectors directory.
TAG=JK_{MAJOR_REVISION}_{MINOR_REVISION}_{RELEASE}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] branch master updated: First pass at doc updates. Will re-check as I do first release from git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git
The following commit(s) were added to refs/heads/master by this push:
new fb5cce8 First pass at doc updates. Will re-check as I do first
release from git
fb5cce8 is described below
commit fb5cce84f88e047554f2956870459902944c3294
Author: Mark Thomas
AuthorDate: Wed Jan 29 18:08:45 2020 +
First pass at doc updates. Will re-check as I do first release from git
---
HOWTO-RELEASE.txt | 16 +++---
native/iis/README | 2 +-
native/scripts/build/unix/buildcheck.sh | 8 +--
xdocs/miscellaneous/changelog.xml | 4 ++
xdocs/miscellaneous/doccontrib.xml | 91 +++--
5 files changed, 35 insertions(+), 86 deletions(-)
diff --git a/HOWTO-RELEASE.txt b/HOWTO-RELEASE.txt
index 7da7334..5a090fe 100644
--- a/HOWTO-RELEASE.txt
+++ b/HOWTO-RELEASE.txt
@@ -20,7 +20,7 @@ Check out a clean copy of tomcat/connectors from subversion to
make sure you don't have any lingering configure or build files.
This will make sure that the source distribution created is clean.
-We assume, that you checked out http://svn.apache.org/repos/asf/tomcat/jk/trunk
+We assume, that you cloned out g...@github.com:apache/tomcat-connectors.git
to a directory named mod_jk. All further path names will be relative to this
directory.
@@ -62,7 +62,7 @@ during release. It is updated with release date after release
process is
completed.
Update the JK_VERISRELEASE define in native/common/jk_version.h, here is
-a svn diff that shows what I changed:
+a git diff that shows what I changed:
Index: native/common/jk_version.h
===
@@ -86,15 +86,13 @@ Use the pattern below for branching and tagging the
tomcat-connectors directory.
TAG=JK_{MAJOR_REVISION}_{MINOR_REVISION}_{RELEASE}
-svn copy \
- https://svn.apache.org/repos/asf/tomcat/jk/trunk/ \
- https://svn.apache.org/repos/asf/tomcat/jk/tags/TAG/
+Here is an example for mod_jk 1.2.47
-Here is an example for mod_jk 1.2.29
+git commit -a -m "Tag JK_1_2_47"
+git tag JK_1_2_47
+git push origin JK_1_2_47
+# reset master
-svn copy \
- https://svn.apache.org/repos/asf/tomcat/jk/trunk/ \
- https://svn.apache.org/repos/asf/tomcat/jk/tags/JK_1.2.29/
Build the mod_jk 1.2 documentation
--
diff --git a/native/iis/README b/native/iis/README
index 29ade2d..6944d93 100644
--- a/native/iis/README
+++ b/native/iis/README
@@ -34,7 +34,7 @@ Obtain the source code:
c:
cd \
- svn co https://svn.apache.org/repos/asf/tomcat/jk/trunk/ tomcat-jk-1.2.x
+ git clone https://github.com/apache/tomcat-connectors.git tomcat-jk-1.2.x
cd tomcat-jk-1.2.x\native\iis
diff --git a/native/scripts/build/unix/buildcheck.sh
b/native/scripts/build/unix/buildcheck.sh
index db119a7..c1fb7c5 100755
--- a/native/scripts/build/unix/buildcheck.sh
+++ b/native/scripts/build/unix/buildcheck.sh
@@ -22,14 +22,14 @@ ac_version=`${AUTOCONF:-autoconf} --version 2>/dev/null|sed
-e 's/^[^0-9]*//;s/[
if test -z "$ac_version"; then
echo "buildconf: autoconf not found."
echo " You need autoconf version 2.59 or newer installed"
-echo " to build mod_jk from SVN."
+echo " to build mod_jk from version control."
exit 1
fi
IFS=.; set $ac_version; IFS=' '
if test "$1" = "2" -a "$2" -lt "59" || test "$1" -lt "2"; then
echo "buildconf: autoconf version $ac_version found."
echo " You need autoconf version 2.59 or newer installed"
-echo " to build mod_jk from SVN."
+echo " to build mod_jk from version control."
exit 1
else
echo "buildconf: autoconf version $ac_version (ok)"
@@ -39,14 +39,14 @@ ac_version=`${LIBTOOL:-libtool} --version 2>/dev/null|sed
-e 's/^[^0-9]*//;s/[a-
if test -z "$ac_version"; then
echo "buildconf: libtool not found."
echo " You need libtool version 1.4 or newer installed"
-echo " to build mod_jk from SVN."
+echo " to build mod_jk from version control."
exit 1
fi
IFS=.; set $ac_version; IFS=' '
if test "$1" = "1" -a "$2" -lt "4" || test "$1" -lt "1"; then
echo "buildconf: libtool version $ac_version found."
echo " You need libtool version 1.4 or newer installed"
-echo " to build mod_jk from SVN."
+echo " to build mod_jk from version control."
exit 1
else
echo "buildconf: libtool version $ac_version (ok)"
diff --git a/xdocs/miscellaneous/changelog.xml
b
[tomcat-native] branch master updated: Replace usage of 'svn' in the documentation with 'git'
This is an automated email from the ASF dual-hosted git repository. mgrigorov pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/master by this push: new 66c8296 Replace usage of 'svn' in the documentation with 'git' 66c8296 is described below commit 66c8296137a80b35e24bda542bb2abb8d8dbae39 Author: Martin Tzvetanov Grigorov AuthorDate: Tue Jan 7 17:17:12 2020 +0200 Replace usage of 'svn' in the documentation with 'git' --- native/BUILDING | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/native/BUILDING b/native/BUILDING index f3dd72b..d175332 100644 --- a/native/BUILDING +++ b/native/BUILDING @@ -22,13 +22,13 @@ Linux / Unix / OSX (dynamic linking) Install OpenSSL version 1.0.2 or higher Install APR version 1.4.0 or higher. - Download and expand the source package or use an svn checkout + Download and expand the source package or use an git checkout > cd native 2. Configure build environment - Note: This step is only required if you are building from an svn checkout. It + Note: This step is only required if you are building from an git checkout. It is not required when building from a source package. > sh buildconf --with-apr=apr_source_location. @@ -88,7 +88,7 @@ Windows 2. Obtain tc-native source - Download and expand the source package or use an svn checkout + Download and expand the source package or use an git checkout 3. Build APR - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 8.5.x updated: Git typo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/7/19 16:29, Mark Thomas wrote: > On 07/12/2019 21:28, ma...@apache.org wrote: >> This is an automated email from the ASF dual-hosted git >> repository. >> >> markt pushed a commit to branch 8.5.x in repository >> https://gitbox.apache.org/repos/asf/tomcat.git >> >> >> The following commit(s) were added to refs/heads/8.5.x by this >> push: new 18de249 Git typo 18de249 is described below >> >> commit 18de2497614152d2ac21122e8458a4cdf828d070 Author: Mark >> Thomas AuthorDate: Sat Dec 7 21:28:02 2019 >> + >> >> Git typo > > I may need to stop soon. I meant "Fix typo". > > Although if there was a "git typo" command that could be very > useful assuming it fixed typos rather than created them. git yer typos here! - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xLBUACgkQHPApP6U8 pFiNOw//edJ3dBHYRQwYnISCmAfLg4acneXRWBagGU2ggIk7Zd+mmu9ZcGAVqbYt ZROgFfWdhiErXGM7Po5m2C2b6GmG2Fj//v7dKoj8D/wr+4Akmy2xzO251RzRPaUR fo+bx8i7wJa64YkduYTPhACqF8YIYBN4y2Bdl1wN3eMY8StXhZ1hbKkY3gU4T+lh CHoxt001/LwRB2Bkn1GW8MCSk3Wx5NIagHqWV1kSeNC6EuPOnTywZwmSEiQvmUYh 9XcpzcFoTZPvQoQLYbOPm+nv3Pt5tjgHgfNbIurP7zHTpHTk2+RN3lWeD1i0I+pU 0TKwFWfVWCYORQpPH7KPjggQ7qJ/rXZKR3tgbrKxSrBc+agE7rFJ/gqVDu/z2+mt ZpId9yDq87aoPPwdAWUogP7n4WCQwOqnNHC9RQCgonJ5ucpj3I6KdzrAmbVno+Vu 0TzlM71pwo8iSR2rCFP2amHnhQXTWV8eOqS+/FkCQeWHxbG8pt9pvxJC5grqtuhU C+cuj5pb+MUYpAJ6QScw66D6Mwxc9E1K/KAXb88DfamWIKlRpwZ/aDeZ9Sa5LCcb iwntIS6y978+X2kQbHZFqix+wTAXRVWsNFfvqkHXwTTcBCKUV445Eztc4BcVs0vX idk/sYO2VX+Aw3xuFP8N0NfthcBQkt56gpLwapZD0TFJPPMFjBg= =dh5g -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 8.5.x updated: Git typo
On 07/12/2019 21:28, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch 8.5.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/8.5.x by this push:
> new 18de249 Git typo
> 18de249 is described below
>
> commit 18de2497614152d2ac21122e8458a4cdf828d070
> Author: Mark Thomas
> AuthorDate: Sat Dec 7 21:28:02 2019 +
>
> Git typo
I may need to stop soon. I meant "Fix typo".
Although if there was a "git typo" command that could be very useful
assuming it fixed typos rather than created them.
Mark
> ---
> java/org/apache/catalina/connector/Request.java | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/java/org/apache/catalina/connector/Request.java
> b/java/org/apache/catalina/connector/Request.java
> index 6bd9f21..201af7d 100644
> --- a/java/org/apache/catalina/connector/Request.java
> +++ b/java/org/apache/catalina/connector/Request.java
> @@ -2698,9 +2698,9 @@ public class Request implements
> org.apache.catalina.servlet4preview.http.HttpSer
> return newSessionId;
> }
>
> -private String rotateSessionId(Manager manager, Session sessiom) {
> +private String rotateSessionId(Manager manager, Session session) {
> if (manager instanceof ManagerBase) {
> -return ((ManagerBase) manager).rotateSessionId(sessiom);
> +return ((ManagerBase) manager).rotateSessionId(session);
> } else {
> String newSessionId = null;
> // Assume there new Id is a duplicate until we prove it isn't.
> The
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Git typo
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 18de249 Git typo
18de249 is described below
commit 18de2497614152d2ac21122e8458a4cdf828d070
Author: Mark Thomas
AuthorDate: Sat Dec 7 21:28:02 2019 +
Git typo
---
java/org/apache/catalina/connector/Request.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/connector/Request.java
b/java/org/apache/catalina/connector/Request.java
index 6bd9f21..201af7d 100644
--- a/java/org/apache/catalina/connector/Request.java
+++ b/java/org/apache/catalina/connector/Request.java
@@ -2698,9 +2698,9 @@ public class Request implements
org.apache.catalina.servlet4preview.http.HttpSer
return newSessionId;
}
-private String rotateSessionId(Manager manager, Session sessiom) {
+private String rotateSessionId(Manager manager, Session session) {
if (manager instanceof ManagerBase) {
-return ((ManagerBase) manager).rotateSessionId(sessiom);
+return ((ManagerBase) manager).rotateSessionId(session);
} else {
String newSessionId = null;
// Assume there new Id is a duplicate until we prove it isn't. The
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-18 um 16:12 schrieb Rémy Maucherat: On Fri, Oct 11, 2019 at 4:20 PM Rémy Maucherat wrote: Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [ ] No Here is a recap of the voting. For the binding votes, we have: Yes: michaelo, ebourg, kkolinko No: remm, schultz, rjung, markt Undecided: fschumacher Thanks to the participants, including the ones with non binding votes who were more in favor of branches. So the community is rather split even if the result leans on the negative side, and many liked the idea of feature branches. I think it's not enough to completely forbid branch use beyond the main release branches. Therefore, I propose resolving this as follows: Branches use should follow a non automatic process: - require a significant amount of work with multiple commits ahead to justify their creation = always a "feature" branch, with the feature being large enough (which is subjective, use common sense) This should have been applied way way earlier. There are too many "fixup", "post fix" commits on master. - get casual community ack before being created (the relevant BZ could get the branch creation request, which should get should get at least one +1 from another committer and of course no vetoes) Seriously? You want me to beg for a cheap branch on an issue I am currently working to solve a problem for the *entire* community? I want to be productive, push intermediate changes and when I think fit, squash them and create the PR with the qualified reviewers assigned. That's what the Apache Maven team and others have been doing for years -- with great success. This pretty much sounds to me that you don't trust your fellow committers doing things right. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
On Fri, Oct 11, 2019 at 4:20 PM Rémy Maucherat wrote: > Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > Should private branches be allowed in the official Tomcat git repository ? > [ ] Yes > [ ] No > Here is a recap of the voting. For the binding votes, we have: Yes: michaelo, ebourg, kkolinko No: remm, schultz, rjung, markt Undecided: fschumacher Thanks to the participants, including the ones with non binding votes who were more in favor of branches. So the community is rather split even if the result leans on the negative side, and many liked the idea of feature branches. I think it's not enough to completely forbid branch use beyond the main release branches. Therefore, I propose resolving this as follows: Branches use should follow a non automatic process: - require a significant amount of work with multiple commits ahead to justify their creation = always a "feature" branch, with the feature being large enough (which is subjective, use common sense) - get casual community ack before being created (the relevant BZ could get the branch creation request, which should get should get at least one +1 from another committer and of course no vetoes) Rémy
Re: [VOTE] Private branches in the official Tomcat git repository
On 11/10/2019 15:20, Rémy Maucherat wrote: > Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as > 8.5.x and 7.0.x. It is possible to do development in private branches > directly in the official Tomcat repository, as an alternative to using > forks and pull requests. > > Should private branches be allowed in the official Tomcat git repository ? > [ ] Yes > [X] No Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-12 um 15:57 schrieb Konstantin Kolinko: пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat : Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [x] Yes [ ] No Certainly Yes. We must be able to conduct our business without relying on GitHub and without relying on its pull requests. +1 If we call them not "private" branches, but "feature" branches - your email concerns will be the same, but many projects are using feature branches. I agree that titling a commit as "First draft" is a bad naming. I would like to see more elaborated commit message, with more context in it. If you remember when we were using Subversion, feature branches were used several times. E.g. I used them to backport testing framework to Tomcat 6. It generated a lot of emails, but their Subject line contained the root path of the commit, and in Subversion such path includes a branch name. It is the very same approach. I am working same as before on features under a Bugzilla issue id. This is not intended to be a playground. As a big github user, i expect main repo to not have unofficially supported code. Technically, the only supported code are the official releases that have passed a vote. Anything else is a work in progress. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 11.10.19 um 16:43 schrieb Rémy Maucherat:
> On Fri, Oct 11, 2019 at 4:30 PM Michael Osipov <mailto:micha...@apache.org>> wrote:
>
> Am 2019-10-11 um 16:20 schrieb Rémy Maucherat:
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> > repository beyond branches that are approved by the community
> such as 8.5.x
> > and 7.0.x. It is possible to do development in private branches
> directly in
> > the official Tomcat repository, as an alternative to using forks
> and pull
> > requests.
> >
> > Should private branches be allowed in the official Tomcat git
> repository ?
> > [ ] Yes
> > [ ] No
>
> I don't like the term 'private' because everytihing I add to the
> canonical repo is intended to merged into upstream sooner or later.
> Purely private stuff must be in a fork anyway.
>
> Please redefine.
>
>
> Well, it's already in the text of the vote ("This vote is to regulate
> the use of branches in the official Tomcat repository beyond branches
> that are approved by the community such as 8.5.x and 7.0.x"): Private
> branches are defined here as any branches whose creation is not
> approved and voted on by the community.
>
> = I feel like creating branch "remm", is it allowed ?
> So I say no, because this is the Tomcat repo, not remm's repo, even
> though commits could possibly be interesting this is a bit too much.
In that sense, I would say "no", too. There is no need for a private
only branch with git.
For feature branches - which I understand are out of scope for this - I
would be tending towards a "yes".
Felix
>
> Rémy
>
>
>
> In that case as depicted by me:
> Yes!
>
Re: [VOTE] Private branches in the official Tomcat git repository
> If we call them not "private" branches, but "feature" branches The "feature" branches is a better name to state these branches. If the feature branch could be created and named after passing a vote which could prevent excessive branches and bad branch name, the branches would be better managed. On Sat, Oct 12, 2019 at 9:57 PM Konstantin Kolinko wrote: > пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat : > > > > Hi, > > > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > > > Should private branches be allowed in the official Tomcat git repository > ? > > [x] Yes > > [ ] No > > Certainly Yes. We must be able to conduct our business without relying > on GitHub and without relying on its pull requests. > > If we call them not "private" branches, but "feature" branches - your > email concerns will be the same, but many projects are using feature > branches. > > > I agree that titling a commit as "First draft" is a bad naming. I > would like to see more elaborated commit message, with more context in > it. > > If you remember when we were using Subversion, feature branches were > used several times. E.g. I used them to backport testing framework to > Tomcat 6. It generated a lot of emails, but their Subject line > contained the root path of the commit, and in Subversion such path > includes a branch name. > > > As a big github user, i expect main repo to not have unofficially > supported code. > > Technically, the only supported code are the official releases that > have passed a vote. Anything else is a work in progress. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Private branches in the official Tomcat git repository
Le sam. 12 oct. 2019 à 15:57, Konstantin Kolinko a écrit : > пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat : > > > > Hi, > > > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > > > Should private branches be allowed in the official Tomcat git repository > ? > > [x] Yes > > [ ] No > > Certainly Yes. We must be able to conduct our business without relying > on GitHub and without relying on its pull requests. > > If we call them not "private" branches, but "feature" branches - your > email concerns will be the same, but many projects are using feature > branches. > > > I agree that titling a commit as "First draft" is a bad naming. I > would like to see more elaborated commit message, with more context in > it. > > If you remember when we were using Subversion, feature branches were > used several times. E.g. I used them to backport testing framework to > Tomcat 6. It generated a lot of emails, but their Subject line > contained the root path of the commit, and in Subversion such path > includes a branch name. > > > As a big github user, i expect main repo to not have unofficially > supported code. > > Technically, the only supported code are the official releases that > have passed a vote. Anything else is a work in progress. > Read it as "external corrupted code". While only committers can push branches it is fine for me. > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Private branches in the official Tomcat git repository
пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat : > > Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > Should private branches be allowed in the official Tomcat git repository ? > [x] Yes > [ ] No Certainly Yes. We must be able to conduct our business without relying on GitHub and without relying on its pull requests. If we call them not "private" branches, but "feature" branches - your email concerns will be the same, but many projects are using feature branches. I agree that titling a commit as "First draft" is a bad naming. I would like to see more elaborated commit message, with more context in it. If you remember when we were using Subversion, feature branches were used several times. E.g. I used them to backport testing framework to Tomcat 6. It generated a lot of emails, but their Subject line contained the root path of the commit, and in Subversion such path includes a branch name. > As a big github user, i expect main repo to not have unofficially supported > code. Technically, the only supported code are the official releases that have passed a vote. Anything else is a work in progress. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 11.10.2019 um 16:20 schrieb Rémy Maucherat: Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [X] No Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
[No] (non binding). As a big github user, i expect main repo to not have unofficially supported code. I work with this kind of setup (for CI) and it is a mess at all layers compared to natural PR structure IMHO. Le sam. 12 oct. 2019 à 02:05, Chuck Caldarale a écrit : > On Oct 11, 2019, at 09:20, Rémy Maucherat wrote: > > > This vote is to regulate the use of branches in the official Tomcat > > repository beyond branches that are approved by the community > > such as 8.5.x and 7.0.x. It is possible to do development in private > > branches directly in the official Tomcat repository, as an alternative > > to using forks and pull requests. > > > Should private branches be allowed in the official Tomcat git repository > ? > [ ] Yes > [x] No > > I’m not a committer, so my vote doesn’t really count, but I am a long-time > Tomcat user and occasional contributer (less these days due to work > priorities). I find the use of personal branches in the public repository > to be at best annoying. > > - Chuck > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Private branches in the official Tomcat git repository
On Oct 11, 2019, at 09:20, Rémy Maucherat wrote: > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community > such as 8.5.x and 7.0.x. It is possible to do development in private > branches directly in the official Tomcat repository, as an alternative > to using forks and pull requests. > Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [x] No I’m not a committer, so my vote doesn’t really count, but I am a long-time Tomcat user and occasional contributer (less these days due to work priorities). I find the use of personal branches in the public repository to be at best annoying. - Chuck - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 10/11/19 10:20, Rémy Maucherat wrote: > Hi, > > This vote is to regulate the use of branches in the official > Tomcat repository beyond branches that are approved by the > community such as 8.5.x and 7.0.x. It is possible to do development > in private branches directly in the official Tomcat repository, as > an alternative to using forks and pull requests. > > Should private branches be allowed in the official Tomcat git > repository ? [ ] Yes [X] No I don't think it makes any sense to have non-standard branches in the public git repository. If you want to make a branch in your own fork, then merge back to one of the "official" branches, then PR to upstream, that makes sense to me. But I don't see any need to create additional "public" branches in the apache/tomcat repo. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2g7XsACgkQHPApP6U8 pFijhBAAyDhBffk317kp64U3ILsaNQ12dh3LyGiNP/12D+bGISRlNu7eRnpNFI9W ig5Acv0mTfO2QhEf9iGjnhZFYcPRabIScIOd5qVSgtKew+9cL7of2HgnOPI8vu2X IwK/I8v+yevEbUDuUEGQ4Zz4zaZAHi8HvynUklMcPYZzp3haEby2HYe41v/lXexS qqmPOgHtxJZb+GKHP1NFb6X7Ljh7Q2Zi+1ZE40M7ErJ+b2DhWXIYKrFQhl5ccTAK J2CnnhcnB7GrIQOll8UqA1qfK0S/APwdYCaZLZ8l0/XDSB8ICnCmTOnYXFBekdro CGUoGFM5b9EPoGv2DOIOrhhOcj+W1esDw5hwZo2KrhmvGM9us2Le7WBtH0H8g2gS xgR5lEJ1NLeb7Zj4tOodZAul6dlRP/NR+H4hrY5fdeeEkbXUXiZ+5bzOptIWyqQ2 OrRnqbZvQivcZNGUyebSqDUbhm/WfB/F/xYMEvGRdMlNs6dFXziOOP1z2iDeUxrH 8IUsxx4RW8kouCTYT1KHGQk+xo5hSg0EUuSVOKp8XAUE70sPMJukW9FEsqpDMx03 1bHzw0vS83MiQEYBW8ePmz5976gU0vzBB/2uXnxW+sIsJB5oo8Nb4AodqJHBGsJj r8upXf9RaOGOjf4J4YyEYkAi+qskzu4F8oIlRysL+8nNAJlVXLA= =XZWe -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Le 11/10/2019 à 16:20, Rémy Maucherat a écrit : > Should private branches be allowed in the official Tomcat git repository ? > [X] Yes > [ ] No +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
> Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > Should private branches be allowed in the official Tomcat git repository ? > [ ] Yes > [X] No In my opinion, I think the branches in Tomcat repo should correspond to the current major maintenance version. Because this can be easily managed. Some middle jobs when solving bug and adding feature should be done in private fork. I consider that the branch in Tomcat repo should be created by *project committer* after a vote and can't be created by anybody casually. On Fri, Oct 11, 2019 at 10:21 PM Rémy Maucherat wrote: > Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > Should private branches be allowed in the official Tomcat git repository ? > [ ] Yes > [ ] No > > Rémy >
Re: [VOTE] Private branches in the official Tomcat git repository
On Fri, Oct 11, 2019 at 4:30 PM Michael Osipov wrote:
> Am 2019-10-11 um 16:20 schrieb Rémy Maucherat:
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> > repository beyond branches that are approved by the community such as
> 8.5.x
> > and 7.0.x. It is possible to do development in private branches directly
> in
> > the official Tomcat repository, as an alternative to using forks and pull
> > requests.
> >
> > Should private branches be allowed in the official Tomcat git repository
> ?
> > [ ] Yes
> > [ ] No
>
> I don't like the term 'private' because everytihing I add to the
> canonical repo is intended to merged into upstream sooner or later.
> Purely private stuff must be in a fork anyway.
>
> Please redefine.
>
Well, it's already in the text of the vote ("This vote is to regulate the
use of branches in the official Tomcat repository beyond branches that are
approved by the community such as 8.5.x and 7.0.x"): Private branches are
defined here as any branches whose creation is not approved and voted on by
the community.
= I feel like creating branch "remm", is it allowed ?
So I say no, because this is the Tomcat repo, not remm's repo, even though
commits could possibly be interesting this is a bit too much.
Rémy
>
> In that case as depicted by me:
> Yes!
>
>
Re: [VOTE] Private branches in the official Tomcat git repository
On Fri, Oct 11, 2019 at 4:20 PM Rémy Maucherat wrote: > Hi, > > This vote is to regulate the use of branches in the official Tomcat > repository beyond branches that are approved by the community such as 8.5.x > and 7.0.x. It is possible to do development in private branches directly in > the official Tomcat repository, as an alternative to using forks and pull > requests. > > Should private branches be allowed in the official Tomcat git repository ? > [ ] Yes > [X] No > > I found branches created a disproportionate amount of email traffic which is rather distracting and not necessarily easy to visually separate from "real" commits on official branches, in addition to requiring subsequent cleanup and maintenance causing further email traffic nuisance. As a result, I believe any early/experimental development work should rather happen in separate git forks and pull requests. Rémy
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-11 um 16:20 schrieb Rémy Maucherat: Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [ ] No I don't like the term 'private' because everytihing I add to the canonical repo is intended to merged into upstream sooner or later. Purely private stuff must be in a fork anyway. Please redefine. In that case as depicted by me: Yes! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Private branches in the official Tomcat git repository
Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [ ] No Rémy
Re: Migrating Tomcat Connectors to Git
On 08/10/2019 13:32, Rainer Jung wrote: > Am 08.10.2019 um 13:39 schrieb Rainer Jung: >> Am 08.10.2019 um 13:09 schrieb Mark Thomas: >>> Hi all, >>> >>> Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There >>> hasn't been much activity on these over the last year or so so there has >>> been no reason to migrate the project to Git. >>> >>> I've recently fixed a mod_jk bug and I have a patch ready to fix a >>> second. These seems like a good time to migrate Tomcat Connectors to >>> git. Therefore, I intend to start this today. >> >> OK for me. >> >> You are probably already aware of the fact, that tools/jkrelease.sh >> has some svn foo in it. To make migration easier, we could comment out >> the features to release from trunk (dev tarball), a branch (also dev >> tarball) or a local directory and for now just keep the part using a >> tag. That makes adjusting the script much easier, especially due to a >> simplification I just committed. > > I have committed a first attempt at making the release skript svn plus > git compatible. We can siplify back, once the switch to git is final. > > When using it with git, there is no support yet for releasing from a > branch, from a (non-verion) tag, from trunk or from a local checkout. I > think these are a not immediately critical. Thanks for this. Tomcat Native has similar code. We can probably use that as a basis for a solution those additional features. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrating Tomcat Connectors to Git
Am 08.10.2019 um 13:39 schrieb Rainer Jung: Am 08.10.2019 um 13:09 schrieb Mark Thomas: Hi all, Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There hasn't been much activity on these over the last year or so so there has been no reason to migrate the project to Git. I've recently fixed a mod_jk bug and I have a patch ready to fix a second. These seems like a good time to migrate Tomcat Connectors to git. Therefore, I intend to start this today. OK for me. You are probably already aware of the fact, that tools/jkrelease.sh has some svn foo in it. To make migration easier, we could comment out the features to release from trunk (dev tarball), a branch (also dev tarball) or a local directory and for now just keep the part using a tag. That makes adjusting the script much easier, especially due to a simplification I just committed. I have committed a first attempt at making the release skript svn plus git compatible. We can siplify back, once the switch to git is final. When using it with git, there is no support yet for releasing from a branch, from a (non-verion) tag, from trunk or from a local checkout. I think these are a not immediately critical. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrating Tomcat Connectors to Git
Am 08.10.2019 um 13:09 schrieb Mark Thomas: Hi all, Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There hasn't been much activity on these over the last year or so so there has been no reason to migrate the project to Git. I've recently fixed a mod_jk bug and I have a patch ready to fix a second. These seems like a good time to migrate Tomcat Connectors to git. Therefore, I intend to start this today. OK for me. You are probably already aware of the fact, that tools/jkrelease.sh has some svn foo in it. To make migration easier, we could comment out the features to release from trunk (dev tarball), a branch (also dev tarball) or a local directory and for now just keep the part using a tag. That makes adjusting the script much easier, especially due to a simplification I just committed. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Migrating Tomcat Connectors to Git
Hi all, Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There hasn't been much activity on these over the last year or so so there has been no reason to migrate the project to Git. I've recently fixed a mod_jk bug and I have a patch ready to fix a second. These seems like a good time to migrate Tomcat Connectors to git. Therefore, I intend to start this today. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 7.0.x updated: Back-port svn->git updates
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/7.0.x by this push: new 4c5f5bb Back-port svn->git updates 4c5f5bb is described below commit 4c5f5bb62c52d64390814128a95dc2e98f8320d3 Author: Mark Thomas AuthorDate: Fri Sep 6 20:33:57 2019 +0100 Back-port svn->git updates --- BUILDING.txt | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/BUILDING.txt b/BUILDING.txt index 89c9f1f..742c72c 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -110,13 +110,13 @@ source distribution, do the following: (3.1) Checkout or obtain the source code for Tomcat @VERSION_MAJOR_MINOR@ -Checkout the source using SVN, selecting a tag for released version or -trunk for the current development code, or download and unpack a source +Clone the source using git, then checkout a specific major branch or +master for the latest code development, or download and unpack a source package. - * Tomcat SVN repository URL: + * Tomcat GitHub repository URL: - https://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/trunk/ +https://github.com/apache/tomcat * Source packages can be downloaded from: @@ -509,15 +509,12 @@ target. The command is: You usually would not need to run this check. You can skip this section. Apache Tomcat project has convention that all of its textual source files, -stored in Subversion repository, are marked with Subversion property -"svn:eol-style" with value of "native". This convention makes the editing -of source code on different platforms easier. +stored in the Git repository, use Unix style LF line endings. This test is used by developers to check that the source code adheres to this convention. It verifies that the ends of lines in textual files are -appropriate for the operating system where it is run. The idea is to run -this check regularly on two different platforms and notify developers when -an inconsistency is detected. +appropriate. The idea is to run this check regularly and notify developers +when an inconsistency is detected. The command to run this test is: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: back-port svn->git updates
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new 13f4296 back-port svn->git updates 13f4296 is described below commit 13f429656b5e798d01c74500ae93774439534360 Author: Mark Thomas AuthorDate: Fri Sep 6 20:33:43 2019 +0100 back-port svn->git updates --- BUILDING.txt | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/BUILDING.txt b/BUILDING.txt index e0811af..8643fb9 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -93,13 +93,13 @@ source distribution, do the following: (3.1) Checkout or obtain the source code for Tomcat @VERSION_MAJOR_MINOR@ -Checkout the source using SVN, selecting a tag for released version or -trunk for the current development code, or download and unpack a source +Clone the source using git, then checkout a specific major branch or +master for the latest code development, or download and unpack a source package. - * Tomcat SVN repository URL: + * Tomcat GitHub repository URL: - https://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/trunk/ +https://github.com/apache/tomcat * Source packages can be downloaded from: @@ -551,15 +551,12 @@ The report file by default is written to You usually would not need to run this check. You can skip this section. Apache Tomcat project has convention that all of its textual source files, -stored in Subversion repository, are marked with Subversion property -"svn:eol-style" with value of "native". This convention makes the editing -of source code on different platforms easier. +stored in the Git repository, use Unix style LF line endings. This test is used by developers to check that the source code adheres to this convention. It verifies that the ends of lines in textual files are -appropriate for the operating system where it is run. The idea is to run -this check regularly on two different platforms and notify developers when -an inconsistency is detected. +appropriate. The idea is to run this check regularly and notify developers +when an inconsistency is detected. The command to run this test is: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/03: Update for migration to git
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 229c6bf6ab37df7bb3bb98a8a6e36b24cbbc062b Author: Mark Thomas AuthorDate: Thu Aug 15 20:40:07 2019 +0100 Update for migration to git --- CONTRIBUTING.md | 49 +++-- 1 file changed, 19 insertions(+), 30 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 28b5ef5..58ea4f9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,7 @@ # Contributing to Apache Tomcat Firstly, thanks for your interest in contributing! I hope that this will be a -pleasant first experience for you, and that you will return to continue +pleasant experience for you, and that you will return to continue contributing. Please visit our [Get Involved page](https://tomcat.apache.org/getinvolved.html) @@ -38,12 +38,12 @@ the issues marked 'Beginner', link below. Please note that the Beginner keyword is pretty new to the project, so if there aren't any issues in the filter feel free to ask on the [dev list](https://tomcat.apache.org/lists.html#tomcat-dev). -* [Beginner issues](https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO=Beginner_type=allwords_id=160824=Tomcat%207=Tomcat%208=Tomcat%209_format=advanced) - +* [Beginner issues](https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO=Beginner_type=allwords_id=160824=Tomcat%207=Tomcat%208.5=Tomcat%209_format=advanced) - issues which should only require a few lines of code, and a test or two to resolve. The list above shows all bugs that are marked 'Beginner' and are open in the -currently supported Tomcat versions (7, 8, and 9). +currently supported Tomcat versions (7, 8.5, and 9). If you prefer C over Java, you may also take a look at the tomcat-native and Tomcat Connectors products in Bugzilla. @@ -53,15 +53,12 @@ Tomcat Connectors products in Bugzilla. Excited yet? This section will guide you through providing a patch to the committers of the project for review and acceptance. -# Chose Your Method of Submission +# Choose Your Method of Submission You can provide a patch in one of the following ways (in order of preference): +* GitHub Pull Request * Patch attachment to the Bugzilla issue -* Github Pull Request -> **Note:** Github is a mirror of the SVN repository that Tomcat is stored in -and therefore it can't be merged outright. Your contribution will be converted -into an SVN patch and committed with a mention of your name for credit. * Email the patch to the developer list. This is not preferred, but if no bug is associated with the patch, or you would like a developer review, an email may be appropriate. @@ -73,51 +70,43 @@ source code. ## Download The Source Distribution -This method works if you want to submit a patch (like you would do for SVN), but +This method works if you want to submit a patch via email, but the difference in using the sources distribution and a VCS is that you have to manually generate the patch file by using diff. If this is what you want, you can download the sources from the "Source Code Distributions" section of the Download Page. There is one such page for every major Tomcat version: + - [Tomcat 9](https://tomcat.apache.org/download-90.cgi) - [Tomcat 8](https://tomcat.apache.org/download-80.cgi) - [Tomcat 7](https://tomcat.apache.org/download-70.cgi) -## SVN +# Manual Patch Generation If you have chosen to attach a patch to the Bugzilla issue (or email -one), then you'll need to checkout the SVN version. Instructions for new -committers to learn how to do this are found -[here](https://www.apache.org/dev/contributors.html#svnbasics). However, in the -interest of a fast ramp up, the short version is below. Note that the root of -the SVN repository is -[tomcat/trunk](http://svn.apache.org/repos/asf/tomcat/trunk), -but you can clone specific versions too, such as -[tc8.5.x](http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/) or even tags ( -[TOMCAT_8_5_15](http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_15/)). +one), then you'll need to download the sources as noted above, make your +desired changes and then manually generate your patch using diff (other +other tool). -``` -$ svn co http://svn.apache.org/repos/asf/tomcat/trunk/ -``` +# GitHub -# Github - -For Github, it's almost the same. Chose the major version that you want (for -now they're in different repositories), fork the repository, and then clone -your fork to do that work. +To submit a GitHub Pull Request you'll need to fork the +[repository](https://github.com/apache/tomcat), clone your fork to do the work: ``` $ git clone https://github.com/$USERNAME/tomcat.git ``` +and then push your changes, and submit a Pull Request v
[tomcat] 03/03: Update source code links to point to Git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit d206509dabe5ea9f40aae1f0448716fd42470456
Author: Mark Thomas
AuthorDate: Thu Aug 15 21:01:20 2019 +0100
Update source code links to point to Git
---
build.properties.default | 3 +++
build.xml | 1 +
webapps/ROOT/index.jsp | 4 ++--
webapps/docs/changelog.xml | 8
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index bfe74e2..66ab7f5 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -29,6 +29,9 @@ version.build=97
version.patch=0
version.suffix=-dev
+# - Source control flags -
+git.branch=7.0.x
+
# - Build control flags -
# Note enabling validation uses Checkstyle which is LGPL licensed
execute.validate=false
diff --git a/build.xml b/build.xml
index ffc0d6e..2f3c724 100644
--- a/build.xml
+++ b/build.xml
@@ -237,6 +237,7 @@
+
diff --git a/webapps/ROOT/index.jsp b/webapps/ROOT/index.jsp
index 6de0008..1d3d46d 100644
--- a/webapps/ROOT/index.jsp
+++ b/webapps/ROOT/index.jsp
@@ -128,7 +128,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
https://tomcat.apache.org/bugreport.html;>Tomcat @VERSION_MAJOR_MINOR@
Bug Database
Tomcat
@VERSION_MAJOR_MINOR@ JavaDocs
-https://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/;>Tomcat
@VERSION_MAJOR_MINOR@ SVN Repository
+https://github.com/apache/tomcat/tree/@GIT_BRANCH@;>Tomcat
@VERSION_MAJOR_MINOR@ Git Repository at GitHub
@@ -183,7 +183,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
Get Involved
Overview
-SVN
Repositories
+Source
Repositories
Mailing
Lists
https://wiki.apache.org/tomcat/FrontPage;>Wiki
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index ec80f54..56895d5 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -112,6 +112,14 @@
+
+
+
+Correct the source code links on the index page for the ROOT web
+application to point to Git rather than Subversion. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Update source code links to point to Git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new abe9d37 Update source code links to point to Git
abe9d37 is described below
commit abe9d37bec0fd100a48bb41800c7ecf3cd7d
Author: Mark Thomas
AuthorDate: Thu Aug 15 21:01:20 2019 +0100
Update source code links to point to Git
---
build.properties.default | 3 +++
build.xml | 1 +
webapps/ROOT/index.jsp | 4 ++--
webapps/docs/changelog.xml | 8
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 563b0db..792b621 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -29,6 +29,9 @@ version.build=46
version.patch=0
version.suffix=-dev
+# - Source control flags -
+git.branch=8.5.x
+
# - Build control flags -
# Note enabling validation uses Checkstyle which is LGPL licensed
execute.validate=false
diff --git a/build.xml b/build.xml
index aeeb2b0..c2aff57 100644
--- a/build.xml
+++ b/build.xml
@@ -245,6 +245,7 @@
+
diff --git a/webapps/ROOT/index.jsp b/webapps/ROOT/index.jsp
index 6de0008..1d3d46d 100644
--- a/webapps/ROOT/index.jsp
+++ b/webapps/ROOT/index.jsp
@@ -128,7 +128,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
https://tomcat.apache.org/bugreport.html;>Tomcat @VERSION_MAJOR_MINOR@
Bug Database
Tomcat
@VERSION_MAJOR_MINOR@ JavaDocs
-https://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/;>Tomcat
@VERSION_MAJOR_MINOR@ SVN Repository
+https://github.com/apache/tomcat/tree/@GIT_BRANCH@;>Tomcat
@VERSION_MAJOR_MINOR@ Git Repository at GitHub
@@ -183,7 +183,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
Get Involved
Overview
-SVN
Repositories
+Source
Repositories
Mailing
Lists
https://wiki.apache.org/tomcat/FrontPage;>Wiki
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 96e92c2..290374d 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -45,6 +45,14 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Correct the source code links on the index page for the ROOT web
+application to point to Git rather than Subversion. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Update source code links to point to Git
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 42971a3 Update source code links to point to Git
42971a3 is described below
commit 42971a30719a557c6c82624b7b55226b393f4bd9
Author: Mark Thomas
AuthorDate: Thu Aug 15 21:01:20 2019 +0100
Update source code links to point to Git
---
build.properties.default | 3 +++
build.xml | 1 +
webapps/ROOT/index.jsp | 4 ++--
webapps/docs/changelog.xml | 8
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 25e83c3..ec173fd 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -29,6 +29,9 @@ version.build=25
version.patch=0
version.suffix=-dev
+# - Source control flags -
+git.branch=master
+
# - Build control flags -
# Note enabling validation uses Checkstyle which is LGPL licensed
ant.version.required=1.9.8
diff --git a/build.xml b/build.xml
index e44fbd9..6690daa 100644
--- a/build.xml
+++ b/build.xml
@@ -239,6 +239,7 @@
+
diff --git a/webapps/ROOT/index.jsp b/webapps/ROOT/index.jsp
index 6de0008..1d3d46d 100644
--- a/webapps/ROOT/index.jsp
+++ b/webapps/ROOT/index.jsp
@@ -128,7 +128,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
https://tomcat.apache.org/bugreport.html;>Tomcat @VERSION_MAJOR_MINOR@
Bug Database
Tomcat
@VERSION_MAJOR_MINOR@ JavaDocs
-https://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/;>Tomcat
@VERSION_MAJOR_MINOR@ SVN Repository
+https://github.com/apache/tomcat/tree/@GIT_BRANCH@;>Tomcat
@VERSION_MAJOR_MINOR@ Git Repository at GitHub
@@ -183,7 +183,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
Get Involved
Overview
-SVN
Repositories
+Source
Repositories
Mailing
Lists
https://wiki.apache.org/tomcat/FrontPage;>Wiki
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d6474dc..de1bcc3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -45,6 +45,14 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Correct the source code links on the index page for the ROOT web
+application to point to Git rather than Subversion. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/02: add .idea project directory to git ignores
This is an automated email from the ASF dual-hosted git repository. violetagg pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit cd4cdca0ff68674a4d1af12a944705f6dc285596 Author: Jeremy Boynes AuthorDate: Sun Jan 26 21:23:55 2014 +0200 add .idea project directory to git ignores git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@1561535 13f79535-47bb-0310-9956-ffa450edef68 (cherry picked from commit 192595113af44907debe8aaa1cd9ac929550fdd7) --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index fe779f2..c845b41 100644 --- a/.gitignore +++ b/.gitignore @@ -28,6 +28,7 @@ mvn.properties .fbprefs .project .settings +.idea *.iml *.asc *.jj - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Git repo for Tomcat Site
Mark, On 7/9/2019 1:45 AM, Mark Thomas wrote: On 09/07/2019 05:29, Igal Sapir wrote: Can we move the Tomcat site to Git? Yes. ASF infra supports both svnpubsub and gitpubsub for websites. There will need to be a little co-ordination with infra as we'd need to switch where the source for the site is pulled from. On the plus side, Tomcat site svn repo is not mirrored to git so we don't need to worry about any of that. I'll look into to the migration process and figure out exactly what is involved. ACK Possibly to a repo named "tomcat-site"? That makes sense. In terms of when, I'd suggest after the 9.0.x and 8.5.x releases have completed. There is usually a quietish period of ~3 weeks between releases when the website doesn't update that much. I think it makes sense to migrate then. All of this is assuming there are no objections to moving. If there are any objections please speak up now so we can discuss any concerns and figure out a way forward everyone is happy with. I'd be happy to make the required changes per prior emails so that we can publish the new design in time for ACNA. Migration to Git and a new design are two separate issues. I'd be happy to see both proceed but I suggest we discuss them separately. I suggest you start a new thread for the discussion about moving to a new design - perhaps with a link to a demo of the latest proposal so we can remind ourselves of what it looks like. True, but it is much easier for me to use Git so personally for me the two issues are not completely unrelated. As of the last communications on the matter the current proposal can be viewed at http://people.apache.org/~isapir/mockups/tomcat-site/ and the open issues are on the DEV mailing list, mostly in the thread https://www.mail-archive.com/dev@tomcat.apache.org/msg131745.html The last discussion on the subject was at https://www.mail-archive.com/dev@tomcat.apache.org/msg132281.html Best, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
