Re: git push ERROR wrt. CI

[Rainer Jung]

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

[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.

Mark

-
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

[Martin Grigorov]

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
> >  > >
> wrote:
> >
> > Rémy,
> >
> > On 4/27/20 18:41, Rémy Maucherat wrote:
> >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
> >>  >> 
> >>  > >> 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

[Coty Sutherland]

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
> >  > >
> wrote:
> >
> > Rémy,
> >
> > On 4/27/20 18:41, Rémy Maucherat wrote:
> >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
> >>  >> 
> >>  > >> 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+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: 

Re: git-fu is (still) weak

[Christopher Schultz]

-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
>  >
wrote:
>
> Rémy,
>
> On 4/27/20 18:41, Rémy Maucherat wrote:
>> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
>> > 
>>  >> 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

[Coty Sutherland]

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
> >  > >
> 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
> >  For additional commands,
> > e-mail: 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

[Christopher Schultz]

-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
>  >
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
>  For additional commands,
> e-mail: 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

[Rémy Maucherat]

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

[Christopher Schultz]

-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

[Michael Osipov]

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

[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?

> 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

[Michael Osipov]

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

[Konstantin Kolinko]

пн, 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

[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.

Emmanuel Bourg


-
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

[Igal Sapir]

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

Re: Git repo for Tomcat Site

[Mark Thomas]

On 09/07/2019 13:09, Violeta Georgieva wrote:
> 
> 
> На вт, 9.07.2019 г. в 11:45 ч. Mark Thomas  > написа:
>>
>> 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.
>>
>> > 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.
> 
> I plan to prepare Tomcat 7 for release this week.

Cool.

I've been looking into the migration and it should be easy so waiting
until after a 7.0.x release shouldn't be an issue.

In short, the steps are:

- Create a new Git repo (we can do this via the self-service portal)
- Import the content (we can do this)
- Switch the source from svn to git (infra / I can do this)
- Move the old svn source to the attic

I think the big question at this point is do we want to try and import
history? I'm leaning towards no because:
- we have it in svn if we need it
- the site doesn't have the same requirements for looking at history as
  the source
- with the Javadocs changing for every release there is a LOT of history

If the consensus is that we should include history then I think it would
be worth running some local experiments to see how long it would take to
construct.

Mark


> 
> Regards,
> Violeta
> 
>>
>> 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.
>>
>> Mark
>>
>>
>> >
>> > Thoughts?
>> >
>> > Igal
>> >
>> >
>> > -
>> > 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
> 


-
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

[Violeta Georgieva]

На вт, 9.07.2019 г. в 11:45 ч. Mark Thomas  написа:
>
> 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.
>
> > 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.

I plan to prepare Tomcat 7 for release this week.

Regards,
Violeta

>
> 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.
>
> Mark
>
>
> >
> > Thoughts?
> >
> > Igal
> >
> >
> > -
> > 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: Git repo for Tomcat Site

[Mark Thomas]

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.

> 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.

Mark


> 
> Thoughts?
> 
> Igal
> 
> 
> -
> 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: Git Migration: What is the svn:eol-style equilvalent?

[Mark Thomas]

On 05/03/2019 17:20, Igal Sapir wrote:
> Coty,
> 
> On Tue, Mar 5, 2019 at 6:23 AM Coty Sutherland  wrote:
> 
>> Hi,
>>
>> I updated the BUILDING and CONTRIBUTING documents so that GitHub users no
>> longer see instructions for SVN after our migration, however I had a few
>> questions. Does anyone know of a git equivalent to svn:eol-style that we
>> should be using? It is mentioned in the "git-svn quirks" section of
>> https://wiki.apache.org/general/GitAtApache, but before trying it I wanted
>> to get some feedback from everyone.
>>
> 
> Do we use CRLF anywhere or do we always use LF everywhere and only adding
> the CRLF when
> archiving as .zip?  If we do use CRLF anywhere, can there be a mixture of
> LF and CRLF in the
> same file?  (I expect not)
> 
> What about .bat files?  I would expect those to always have CRLF, no?  Git
> has a config
> file called .gitattributes [1] which allows to set the ending according to
> the file type (pattern), e.g.
> 
> *.battext eol=crlf
> 
> Another option to consider is core.eol [2].

The svn policy was to always use platform line-endings on checkout (so
you could easy edit .bat files on Linux and .sh on Windows) and 'fix'
the line endings during the build process.

Mark


> 
> Thanks,
> 
> Igal
> 
> [1] https://git-scm.com/docs/gitattributes
> [2] https://git-scm.com/docs/git-config#git-config-coreeol
> 
> 
> 
>>
>> Secondly, the SVN references in MERGE.txt should be cleaned up at this
>> point, right? Is the git section still up to date (I see it was updated
>> last on Jan 29, so probably)?
>>
>>
>>
>> Thanks!
>> Coty
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git Migration: What is the svn:eol-style equilvalent?

[Mark Thomas]

On 05/03/2019 14:23, Coty Sutherland wrote:
> Hi,
> 
> I updated the BUILDING and CONTRIBUTING documents so that GitHub users no
> longer see instructions for SVN after our migration, however I had a few
> questions. Does anyone know of a git equivalent to svn:eol-style that we
> should be using? It is mentioned in the "git-svn quirks" section of
> https://wiki.apache.org/general/GitAtApache, but before trying it I wanted
> to get some feedback from everyone.

Reading

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

It looks like we want:
Windows:
git config --global core.autocrlf true
Linux/OSX:
git config --global core.autocrlf input


> Secondly, the SVN references in MERGE.txt should be cleaned up at this
> point, right?

Now or the next time we pull in a set of changes. Commons is in the
process of moving (has moved?) all the active components to git so there
is something to be said for leaving it until we next do a merge and
updating then once all of Commons is on Git.

> Is the git section still up to date (I see it was updated
> last on Jan 29, so probably)?

It is.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git Migration: What is the svn:eol-style equilvalent?

[Igal Sapir]

Coty,

On Tue, Mar 5, 2019 at 6:23 AM Coty Sutherland  wrote:

> Hi,
>
> I updated the BUILDING and CONTRIBUTING documents so that GitHub users no
> longer see instructions for SVN after our migration, however I had a few
> questions. Does anyone know of a git equivalent to svn:eol-style that we
> should be using? It is mentioned in the "git-svn quirks" section of
> https://wiki.apache.org/general/GitAtApache, but before trying it I wanted
> to get some feedback from everyone.
>

Do we use CRLF anywhere or do we always use LF everywhere and only adding
the CRLF when
archiving as .zip?  If we do use CRLF anywhere, can there be a mixture of
LF and CRLF in the
same file?  (I expect not)

What about .bat files?  I would expect those to always have CRLF, no?  Git
has a config
file called .gitattributes [1] which allows to set the ending according to
the file type (pattern), e.g.

*.battext eol=crlf

Another option to consider is core.eol [2].

Thanks,

Igal

[1] https://git-scm.com/docs/gitattributes
[2] https://git-scm.com/docs/git-config#git-config-coreeol



>
> Secondly, the SVN references in MERGE.txt should be cleaned up at this
> point, right? Is the git section still up to date (I see it was updated
> last on Jan 29, so probably)?
>
>
>
> Thanks!
> Coty
>

Re: Git migration read for testing

[Igal Sapir]

Using an SSH remote URL has resolved the issue for me.  Thank you.

On Sat, Mar 2, 2019 at 1:35 PM Igal Sapir  wrote:

> On Wed, Feb 27, 2019 at 2:09 AM Mark Thomas  wrote:
>
>> On 27/02/2019 09:44, Rémy Maucherat wrote:
>> > On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
>> >
>> >> All,
>> >>
>> >> https://github.com/apache/tomcat
>> >
>> > Trying my test commit, I can't push to the github repo. I probably
>> missed
>> > something obvious.
>>
>> You need to make sure you have three green ticks here:
>> https://gitbox.apache.org/setup/
>>
>> If you haven't linked your ASF and GitHub accounts or setup MFA then it
>> can take an hour or so after you make those changes for write access to
>> be enabled (various systems need to sync in the background).
>>
>
> I have the three green ticks with the message "Write access granted" on
> gitbox.apache.org/setup (for a couple of days now), but am still unable
> to push a commit.
>
> My remote is set using https:
> $ git remote -v
> originhttps://github.com/apache/tomcat (fetch)
> originhttps://github.com/apache/tomcat (push)
>
> I've created a Personal Access Token with admin:org scope and tried
> logging in with it and my GitHub username, but still no go.
>
> Any ideas?  Thanks,
>
> Igal
>
>

Re: Git migration read for testing

[Igal Sapir]

On Wed, Feb 27, 2019 at 2:09 AM Mark Thomas  wrote:

> On 27/02/2019 09:44, Rémy Maucherat wrote:
> > On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> >
> >> All,
> >>
> >> https://github.com/apache/tomcat
> >
> > Trying my test commit, I can't push to the github repo. I probably missed
> > something obvious.
>
> You need to make sure you have three green ticks here:
> https://gitbox.apache.org/setup/
>
> If you haven't linked your ASF and GitHub accounts or setup MFA then it
> can take an hour or so after you make those changes for write access to
> be enabled (various systems need to sync in the background).
>

I have the three green ticks with the message "Write access granted" on
gitbox.apache.org/setup (for a couple of days now), but am still unable to
push a commit.

My remote is set using https:
$ git remote -v
originhttps://github.com/apache/tomcat (fetch)
originhttps://github.com/apache/tomcat (push)

I've created a Personal Access Token with admin:org scope and tried logging
in with it and my GitHub username, but still no go.

Any ideas?  Thanks,

Igal

Re: Git migration read for testing

[Michael Osipov]

Am 2019-03-01 um 21:50 schrieb Mark Thomas:

On 01/03/2019 19:54, Mark Thomas wrote:

On 01/03/2019 19:00, Coty Sutherland wrote:

The email notifications work for when we push commits to the repository,
but it looks like we're missing emails when PRs are opened.


ACK. I'll talk to infra.


Fixed.

FYI we have the option to route commits to one location and PRs +
comments to another. At the moment, everything goes to dev@

Some projects have separate commits@ and notifications@ lists (and
possibly issues@ as well).

Personally, I like it all in one place and tend to filter everything
into a single folder anyway. But I wanted to mention that the option was
there.


I'd opt for commits to commits@ and PRs to dev@. For those who'd like 
see commits will need to subscribe to it. Commits on dev@ produce a lot 
of traffic not necessarily related to dev discusssions.


Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Mark Thomas]

On 01/03/2019 20:58, Rémy Maucherat wrote:
> On Fri, Mar 1, 2019 at 9:50 PM Mark Thomas  wrote:
> 
>> On 01/03/2019 19:54, Mark Thomas wrote:
>>> On 01/03/2019 19:00, Coty Sutherland wrote:
 The email notifications work for when we push commits to the repository,
 but it looks like we're missing emails when PRs are opened.
>>>
>>> ACK. I'll talk to infra.
>>
>> Fixed.
>>
> 
> Looks like it :)
> 
>>
>> FYI we have the option to route commits to one location and PRs +
>> comments to another. At the moment, everything goes to dev@
>>
>> Some projects have separate commits@ and notifications@ lists (and
>> possibly issues@ as well).
>>
>> Personally, I like it all in one place and tend to filter everything
>> into a single folder anyway. But I wanted to mention that the option was
>> there.
>>
> 
> It is true other projects may have more mailing lists, but I'm not
> convinced right now.
> 
> BTW, I made a commit on github one hour ago, but it still isn't on gitbox.
> Isn't this bad ?

Infra have been dealing with some abusive traffic to Gitbox. It got
behind. I think I can manually sync it. Let me look. Yes, I can. Done.
Hmm. I might need to manually trigger the commit mails...

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Rémy Maucherat]

On Fri, Mar 1, 2019 at 9:50 PM Mark Thomas  wrote:

> On 01/03/2019 19:54, Mark Thomas wrote:
> > On 01/03/2019 19:00, Coty Sutherland wrote:
> >> The email notifications work for when we push commits to the repository,
> >> but it looks like we're missing emails when PRs are opened.
> >
> > ACK. I'll talk to infra.
>
> Fixed.
>

Looks like it :)

>
> FYI we have the option to route commits to one location and PRs +
> comments to another. At the moment, everything goes to dev@
>
> Some projects have separate commits@ and notifications@ lists (and
> possibly issues@ as well).
>
> Personally, I like it all in one place and tend to filter everything
> into a single folder anyway. But I wanted to mention that the option was
> there.
>

It is true other projects may have more mailing lists, but I'm not
convinced right now.

BTW, I made a commit on github one hour ago, but it still isn't on gitbox.
Isn't this bad ?

Rémy

Re: Git migration read for testing

[Mark Thomas]

On 01/03/2019 19:54, Mark Thomas wrote:
> On 01/03/2019 19:00, Coty Sutherland wrote:
>> The email notifications work for when we push commits to the repository,
>> but it looks like we're missing emails when PRs are opened.
> 
> ACK. I'll talk to infra.

Fixed.

FYI we have the option to route commits to one location and PRs +
comments to another. At the moment, everything goes to dev@

Some projects have separate commits@ and notifications@ lists (and
possibly issues@ as well).

Personally, I like it all in one place and tend to filter everything
into a single folder anyway. But I wanted to mention that the option was
there.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Mark Thomas]

On 01/03/2019 19:00, Coty Sutherland wrote:
> The email notifications work for when we push commits to the repository,
> but it looks like we're missing emails when PRs are opened.

ACK. I'll talk to infra.

Mark

> 
> On Wed, Feb 27, 2019 at 9:03 AM Rémy Maucherat  wrote:
> 
>> On Wed, Feb 27, 2019 at 11:09 AM Mark Thomas  wrote:
>>
>>> On 27/02/2019 09:44, Rémy Maucherat wrote:
 On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:

> All,
>
> https://github.com/apache/tomcat


 Trying my test commit, I can't push to the github repo. I probably
>> missed
 something obvious.
>>>
>>> You need to make sure you have three green ticks here:
>>> https://gitbox.apache.org/setup/
>>>
>>> If you haven't linked your ASF and GitHub accounts or setup MFA then it
>>> can take an hour or so after you make those changes for write access to
>>> be enabled (various systems need to sync in the background).
>>>
>>
>> I had forgotten about this as the Tomcat repo commit info was already
>> linked to my account. Thanks for the help !
>>
>> Rémy
>>
>>
>>>
>>> Mark
>>>
>>>

 Rémy


>
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>
> Tags:
> - one for each 7.0.x, 8.5.x and 9.0.x release
>
> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> version number where modifier is RC or M.
>
> The repository is probably read/write for all committers now but
>> please
> refrain from making any changes until we confirm that all is well.
>
> If you have some time available now, please test this new repository
>> and
> report and questions or concerns to this thread.
>
> Assuming no issues are discovered, I'd like to formally move over to
>> git
> later today.
>
> Mark
>
> -
> 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
>>>
>>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Coty Sutherland]

The email notifications work for when we push commits to the repository,
but it looks like we're missing emails when PRs are opened.

On Wed, Feb 27, 2019 at 9:03 AM Rémy Maucherat  wrote:

> On Wed, Feb 27, 2019 at 11:09 AM Mark Thomas  wrote:
>
> > On 27/02/2019 09:44, Rémy Maucherat wrote:
> > > On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> > >
> > >> All,
> > >>
> > >> https://github.com/apache/tomcat
> > >
> > >
> > > Trying my test commit, I can't push to the github repo. I probably
> missed
> > > something obvious.
> >
> > You need to make sure you have three green ticks here:
> > https://gitbox.apache.org/setup/
> >
> > If you haven't linked your ASF and GitHub accounts or setup MFA then it
> > can take an hour or so after you make those changes for write access to
> > be enabled (various systems need to sync in the background).
> >
>
> I had forgotten about this as the Tomcat repo commit info was already
> linked to my account. Thanks for the help !
>
> Rémy
>
>
> >
> > Mark
> >
> >
> > >
> > > Rémy
> > >
> > >
> > >>
> > >>
> > >> is now ready for testing.
> > >>
> > >> It should contain:
> > >> branches
> > >> - master (9.0.x)
> > >> - 8.5.x
> > >> - 7.0.x
> > >>
> > >> Tags:
> > >> - one for each 7.0.x, 8.5.x and 9.0.x release
> > >>
> > >> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> > >> version number where modifier is RC or M.
> > >>
> > >> The repository is probably read/write for all committers now but
> please
> > >> refrain from making any changes until we confirm that all is well.
> > >>
> > >> If you have some time available now, please test this new repository
> and
> > >> report and questions or concerns to this thread.
> > >>
> > >> Assuming no issues are discovered, I'd like to formally move over to
> git
> > >> later today.
> > >>
> > >> Mark
> > >>
> > >> -
> > >> 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: Git migration read for testing

[Rémy Maucherat]

On Wed, Feb 27, 2019 at 11:09 AM Mark Thomas  wrote:

> On 27/02/2019 09:44, Rémy Maucherat wrote:
> > On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> >
> >> All,
> >>
> >> https://github.com/apache/tomcat
> >
> >
> > Trying my test commit, I can't push to the github repo. I probably missed
> > something obvious.
>
> You need to make sure you have three green ticks here:
> https://gitbox.apache.org/setup/
>
> If you haven't linked your ASF and GitHub accounts or setup MFA then it
> can take an hour or so after you make those changes for write access to
> be enabled (various systems need to sync in the background).
>

I had forgotten about this as the Tomcat repo commit info was already
linked to my account. Thanks for the help !

Rémy


>
> Mark
>
>
> >
> > Rémy
> >
> >
> >>
> >>
> >> is now ready for testing.
> >>
> >> It should contain:
> >> branches
> >> - master (9.0.x)
> >> - 8.5.x
> >> - 7.0.x
> >>
> >> Tags:
> >> - one for each 7.0.x, 8.5.x and 9.0.x release
> >>
> >> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> >> version number where modifier is RC or M.
> >>
> >> The repository is probably read/write for all committers now but please
> >> refrain from making any changes until we confirm that all is well.
> >>
> >> If you have some time available now, please test this new repository and
> >> report and questions or concerns to this thread.
> >>
> >> Assuming no issues are discovered, I'd like to formally move over to git
> >> later today.
> >>
> >> Mark
> >>
> >> -
> >> 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: Git migration read for testing

[Mark Thomas]

On 27/02/2019 09:44, Rémy Maucherat wrote:
> On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> 
>> All,
>>
>> https://github.com/apache/tomcat
> 
> 
> Trying my test commit, I can't push to the github repo. I probably missed
> something obvious.

You need to make sure you have three green ticks here:
https://gitbox.apache.org/setup/

If you haven't linked your ASF and GitHub accounts or setup MFA then it
can take an hour or so after you make those changes for write access to
be enabled (various systems need to sync in the background).

Mark


> 
> Rémy
> 
> 
>>
>>
>> is now ready for testing.
>>
>> It should contain:
>> branches
>> - master (9.0.x)
>> - 8.5.x
>> - 7.0.x
>>
>> Tags:
>> - one for each 7.0.x, 8.5.x and 9.0.x release
>>
>> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
>> version number where modifier is RC or M.
>>
>> The repository is probably read/write for all committers now but please
>> refrain from making any changes until we confirm that all is well.
>>
>> If you have some time available now, please test this new repository and
>> report and questions or concerns to this thread.
>>
>> Assuming no issues are discovered, I'd like to formally move over to git
>> later today.
>>
>> Mark
>>
>> -
>> 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: Git migration read for testing

[Rémy Maucherat]

On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:

> All,
>
> https://github.com/apache/tomcat


Trying my test commit, I can't push to the github repo. I probably missed
something obvious.

Rémy


>
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>
> Tags:
> - one for each 7.0.x, 8.5.x and 9.0.x release
>
> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> version number where modifier is RC or M.
>
> The repository is probably read/write for all committers now but please
> refrain from making any changes until we confirm that all is well.
>
> If you have some time available now, please test this new repository and
> report and questions or concerns to this thread.
>
> Assuming no issues are discovered, I'd like to formally move over to git
> later today.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Git migration read for testing

[Igal Sapir]

Konstantin,

On Tue, Feb 26, 2019 at 4:23 PM Konstantin Kolinko 
wrote:

> вт, 26 февр. 2019 г. в 21:24, Igal Sapir :
> >
> > Mark,
> >
> > On Tue, Feb 26, 2019 at 4:33 AM Mark Thomas  wrote:
> >
> > > 
> > > branches
> > > - master (9.0.x)
> > > - 8.5.x
> > > - 7.0.x
> >
> > What are the plans for the tomcat-site?  [...]
>
> Igal,
>
> If you look at a *-fulldocs.tar.gz file with full documentation that
> accompanies each Tomcat release,
> you'll find that e.g. for Tomcat 9.0.16 its unpacked size is 60 Mb,
> with 2385 files in 165 directories.
>
> The full tomcat.apache.org site contains such documentation for every
> major version of Tomcat. See all directories listed ar
> http://svn.apache.org/viewvc/tomcat/site/trunk/docs/
>
>
With Subversion it is easy to work with that, using "sparse checkout"
> feature. The relevant commands are documented in site's README file.
>

Git is much more efficient than Subversion, as it only keeps a single copy
of files that were unchanged.  The new github repo takes on my drive 133.2
MiB for the 3 branches combined with the master branch checked out (125.6
MiB when the 7.0.x branch is checked out as less files get uncompressed).


>
> With some googling, it seems that Git also has some sparse checkout
> support [1], but I am not sure whether it is as easy to use as this
> feature in Subversion.
>
> (How does one manage the checkout layout? Is there a better way to
> update the ".git/info/sparse-checkout" file rather than having to edit
> it by manually? In Subversion the checkout depth can be changed easily
> with "svn update --set-depth" command).
>

In Git you don't have to get a partial depth due to the efficiency
mentioned above - you get the whole depth at no additional cost.  If you
have for example a file that hasn't been changed in any commit from 7.0.1
to 9.0.16 then Git keeps only one copy of it across all branches throughout
the repository.


> If people really want to use git for the site, I think the first step
> it to create a Git mirror for the current site repository and to see
> whether it is usable.
>

I have created a local git repo from the site branch.  From what I see the
most disk space goes for the JavaDoc sections, and some on the docs
directory. These are generated files so they can be added to .gitignore and
not tracked by Git.


> At this point, I think that Subversion is better tool for managing the
> site. I do not expect much from Git.
>

I agree with you that ideally the site should not be mixed with the source
code.  The tomcat-site should have its own repository.  A GitHub search
shows that the apache account has 94 repositories with `site` in the name
[1].  So for example there are repos like `kafka-site` and `spark-website`
in addition to the `kafka` and `spark` source code repositories.

All we have to do is create a separate repo for the site, either
`tomcat-website` or `tomcat-site`.  I believe that INFRA takes care of that.

Best,

Igal

[1] https://github.com/search?q=org%3Aapache+site=Repositories

Re: Git migration read for testing

[Konstantin Kolinko]

вт, 26 февр. 2019 г. в 21:24, Igal Sapir :
>
> Mark,
>
> On Tue, Feb 26, 2019 at 4:33 AM Mark Thomas  wrote:
>
> > All,
> >
> > https://github.com/apache/tomcat
> >
> > is now ready for testing.
> >
> > It should contain:
> > branches
> > - master (9.0.x)
> > - 8.5.x
> > - 7.0.x
> >
>
> What are the plans for the tomcat-site?  [...]

Igal,

If you look at a *-fulldocs.tar.gz file with full documentation that
accompanies each Tomcat release,
you'll find that e.g. for Tomcat 9.0.16 its unpacked size is 60 Mb,
with 2385 files in 165 directories.

The full tomcat.apache.org site contains such documentation for every
major version of Tomcat. See all directories listed ar
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/

With Subversion it is easy to work with that, using "sparse checkout"
feature. The relevant commands are documented in site's README file.

With some googling, it seems that Git also has some sparse checkout
support [1], but I am not sure whether it is as easy to use as this
feature in Subversion.

(How does one manage the checkout layout? Is there a better way to
update the ".git/info/sparse-checkout" file rather than having to edit
it by manually? In Subversion the checkout depth can be changed easily
with "svn update --set-depth" command).

If people really want to use git for the site, I think the first step
it to create a Git mirror for the current site repository and to see
whether it is usable.

At this point, I think that Subversion is better tool for managing the
site. I do not expect much from Git.

[1] https://briancoyner.github.io/2013/06/05/git-sparse-checkout.html

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 migration read for testing

[Igal Sapir]

On Tue, Feb 26, 2019 at 11:28 AM Mark Thomas  wrote:

> On 26/02/2019 18:23, Igal Sapir wrote:
> > Mark,
> >
> > On Tue, Feb 26, 2019 at 4:33 AM Mark Thomas  wrote:
> >
> >> All,
> >>
> >> https://github.com/apache/tomcat
> >>
> >> is now ready for testing.
> >>
> >> It should contain:
> >> branches
> >> - master (9.0.x)
> >> - 8.5.x
> >> - 7.0.x
> >>
> >
> > What are the plans for the tomcat-site?
>
> Migrate to git-pub-sub from svn-pub-sub at some point. Timing TBD.
>
> >  I am working on the new site
> > design and will soon be ready to push the changes.
> >
> > I will first upload a full working version to a temporary location for
> > review.
>
> Cool.
>
> > How will the site's source directory be wired to tomcat.apache.org?  Do
> we
> > need to request INFRA to set it up?
>
> We'll need a branch called asf-site and that needs to contain the site's
> content which should consist entirely of static files. How we generate
> the content of that branch from (presumably) master is up to us.
>
> We can set this git repo up whenever we want. We can do it now if it
> makes it easier for you.
>

No rush on my end since I can always push the changes to a repo on my own
GitHub account and we can later merge it.

I thought that it might be easier for you since you're already working on
that and I wanted to make sure that we don't "forget" it, so whenever it
works for you is fine by me.

Thanks,

Igal

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 18:23, Igal Sapir wrote:
> Mark,
> 
> On Tue, Feb 26, 2019 at 4:33 AM Mark Thomas  wrote:
> 
>> All,
>>
>> https://github.com/apache/tomcat
>>
>> is now ready for testing.
>>
>> It should contain:
>> branches
>> - master (9.0.x)
>> - 8.5.x
>> - 7.0.x
>>
> 
> What are the plans for the tomcat-site?

Migrate to git-pub-sub from svn-pub-sub at some point. Timing TBD.

>  I am working on the new site
> design and will soon be ready to push the changes.
> 
> I will first upload a full working version to a temporary location for
> review.

Cool.

> How will the site's source directory be wired to tomcat.apache.org?  Do we
> need to request INFRA to set it up?

We'll need a branch called asf-site and that needs to contain the site's
content which should consist entirely of static files. How we generate
the content of that branch from (presumably) master is up to us.

We can set this git repo up whenever we want. We can do it now if it
makes it easier for you.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Igal Sapir]

Mark,

On Tue, Feb 26, 2019 at 4:33 AM Mark Thomas  wrote:

> All,
>
> https://github.com/apache/tomcat
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>

What are the plans for the tomcat-site?  I am working on the new site
design and will soon be ready to push the changes.

I will first upload a full working version to a temporary location for
review.

How will the site's source directory be wired to tomcat.apache.org?  Do we
need to request INFRA to set it up?

Best,

Igal

Re: Git migration read for testing

[Igal Sapir]

On Tue, Feb 26, 2019 at 6:45 AM Mark Thomas  wrote:

> On 26/02/2019 13:54, Rémy Maucherat wrote:
> > On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> >
> >> All,
> >>
> >> https://github.com/apache/tomcat
> >>
> >> is now ready for testing.
> >>
> >
> > That looks quite good :)
>

+1.  Looks good to me.


> >
> > Should we plan to all work with PRs for large changes ?
>
> That sounds like a better way of doing what we have done in the past
> with large proposed patches.
>

+1


>
> I've just discovered that the Eclipse IDE does not support Git
> worktrees. I'm not sure how much of a nuisance that is going to turn out
> to be. IntelliJ IDEA does support worktrees and JetBrains offer open
> source licenses so I've applied for one. I'm not sure the benefit of
> worktree support is going to be worth the pain of switching IDEs. I
> guess I'll find out...
>

I find IntelliJ to be much superior to Eclipse.  JetBrains does offer
license which is very generous of them, but I find that for Java (IDEA, as
opposed to some of their other products) even the free, community edition,
is more than sufficient and possibly also lighter than the Ultimate edition.

Igal

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 16:20, Mark Thomas wrote:
> On 26/02/2019 15:25, Huxing Zhang wrote:
>> Hi,
>>
>> It looks good to me.
>>
>> I think it is better to add some description and tags in the headline
>> of Github, to make it more informative and searchable.
>>
>> For example: Apache Tomcat® is an open source implementation of the
>> Java Servlet, JavaServer Pages, Java Expression Language and Java
>> WebSocket technologies.
>>
>> Also I think the CONTRIBUTING file need to be update, to deprecate the
>> usage of svn.
>>
>> Further search using SVN as keyword in the repo shows more work need
>> to be updated.
> 
> Indeed. There are a whole bunch of things that will need to be updated
> assuming we decide we are happy with the new repos.
> 
> So far all looks good. I'm just trying to work through with infra why we
> saw 2 commit emails.

Appears to be a one-off glitch.

I'm going to tell infra all is well and they can remove the tomcat85 and
tomcat70 mirrors from github.

The git repo is now officially read/write and can be used via either of:
https://gitbox.apache.org/repos/asf/tomcat.git
https://github.com/apache/tomcat

I'm going to start updating docs, CI systems etc. As part of those
updates, I'll move the svn repos to tomcat/archive

Mark


> 
> Mark
> 
> 
>>
>> [1] https://github.com/apache/tomcat/blob/master/CONTRIBUTING.md
>>
>> On Tue, Feb 26, 2019 at 8:33 PM Mark Thomas  wrote:
>>>
>>> All,
>>>
>>> https://github.com/apache/tomcat
>>>
>>> is now ready for testing.
>>>
>>> It should contain:
>>> branches
>>> - master (9.0.x)
>>> - 8.5.x
>>> - 7.0.x
>>>
>>> Tags:
>>> - one for each 7.0.x, 8.5.x and 9.0.x release
>>>
>>> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
>>> version number where modifier is RC or M.
>>>
>>> The repository is probably read/write for all committers now but please
>>> refrain from making any changes until we confirm that all is well.
>>>
>>> If you have some time available now, please test this new repository and
>>> report and questions or concerns to this thread.
>>>
>>> Assuming no issues are discovered, I'd like to formally move over to git
>>> later today.
>>>
>>> Mark
>>>
>>> -
>>> 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
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Michael Osipov]

Am 2019-02-26 um 13:33 schrieb Mark Thomas:

All,

https://github.com/apache/tomcat

is now ready for testing.

It should contain:
branches
- master (9.0.x)
- 8.5.x
- 7.0.x

Tags:
- one for each 7.0.x, 8.5.x and 9.0.x release

Tags have all been renamed to follow a a.b.c-MODIFIERn format for
version number where modifier is RC or M.


That looks so sweet and tidy. I cannot clone the repo at the moment, 
Gitbox seems to be down in EU.


Thank you for your effort!

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 15:25, Huxing Zhang wrote:
> Hi,
> 
> It looks good to me.
> 
> I think it is better to add some description and tags in the headline
> of Github, to make it more informative and searchable.
> 
> For example: Apache Tomcat® is an open source implementation of the
> Java Servlet, JavaServer Pages, Java Expression Language and Java
> WebSocket technologies.
> 
> Also I think the CONTRIBUTING file need to be update, to deprecate the
> usage of svn.
> 
> Further search using SVN as keyword in the repo shows more work need
> to be updated.

Indeed. There are a whole bunch of things that will need to be updated
assuming we decide we are happy with the new repos.

So far all looks good. I'm just trying to work through with infra why we
saw 2 commit emails.

Mark


> 
> [1] https://github.com/apache/tomcat/blob/master/CONTRIBUTING.md
> 
> On Tue, Feb 26, 2019 at 8:33 PM Mark Thomas  wrote:
>>
>> All,
>>
>> https://github.com/apache/tomcat
>>
>> is now ready for testing.
>>
>> It should contain:
>> branches
>> - master (9.0.x)
>> - 8.5.x
>> - 7.0.x
>>
>> Tags:
>> - one for each 7.0.x, 8.5.x and 9.0.x release
>>
>> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
>> version number where modifier is RC or M.
>>
>> The repository is probably read/write for all committers now but please
>> refrain from making any changes until we confirm that all is well.
>>
>> If you have some time available now, please test this new repository and
>> report and questions or concerns to this thread.
>>
>> Assuming no issues are discovered, I'd like to formally move over to git
>> later today.
>>
>> Mark
>>
>> -
>> 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: Git migration read for testing

[Michael Osipov]

Am 2019-02-26 um 14:54 schrieb Rémy Maucherat:

On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:


All,

https://github.com/apache/tomcat

is now ready for testing.

It should contain:
branches
- master (9.0.x)
- 8.5.x
- 7.0.x

Tags:
- one for each 7.0.x, 8.5.x and 9.0.x release

Tags have all been renamed to follow a a.b.c-MODIFIERn format for
version number where modifier is RC or M.

The repository is probably read/write for all committers now but please
refrain from making any changes until we confirm that all is well.

If you have some time available now, please test this new repository and
report and questions or concerns to this thread.

Assuming no issues are discovered, I'd like to formally move over to git
later today.



That looks quite good :)

Should we plan to all work with PRs for large changes ?


I'd love to have this, giving some time for the community to watch over 
the change...and assigning reviewers to it.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Huxing Zhang]

Hi,

It looks good to me.

I think it is better to add some description and tags in the headline
of Github, to make it more informative and searchable.

For example: Apache Tomcat® is an open source implementation of the
Java Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

Also I think the CONTRIBUTING file need to be update, to deprecate the
usage of svn.

Further search using SVN as keyword in the repo shows more work need
to be updated.

[1] https://github.com/apache/tomcat/blob/master/CONTRIBUTING.md

On Tue, Feb 26, 2019 at 8:33 PM Mark Thomas  wrote:
>
> All,
>
> https://github.com/apache/tomcat
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>
> Tags:
> - one for each 7.0.x, 8.5.x and 9.0.x release
>
> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> version number where modifier is RC or M.
>
> The repository is probably read/write for all committers now but please
> refrain from making any changes until we confirm that all is well.
>
> If you have some time available now, please test this new repository and
> report and questions or concerns to this thread.
>
> Assuming no issues are discovered, I'd like to formally move over to git
> later today.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>


-- 
Best Regards！
Huxing

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 13:54, Rémy Maucherat wrote:
> On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:
> 
>> All,
>>
>> https://github.com/apache/tomcat
>>
>> is now ready for testing.
>>
>> It should contain:
>> branches
>> - master (9.0.x)
>> - 8.5.x
>> - 7.0.x
>>
>> Tags:
>> - one for each 7.0.x, 8.5.x and 9.0.x release
>>
>> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
>> version number where modifier is RC or M.
>>
>> The repository is probably read/write for all committers now but please
>> refrain from making any changes until we confirm that all is well.
>>
>> If you have some time available now, please test this new repository and
>> report and questions or concerns to this thread.
>>
>> Assuming no issues are discovered, I'd like to formally move over to git
>> later today.
>>
> 
> That looks quite good :)
> 
> Should we plan to all work with PRs for large changes ?

That sounds like a better way of doing what we have done in the past
with large proposed patches.

I've just discovered that the Eclipse IDE does not support Git
worktrees. I'm not sure how much of a nuisance that is going to turn out
to be. IntelliJ IDEA does support worktrees and JetBrains offer open
source licenses so I've applied for one. I'm not sure the benefit of
worktree support is going to be worth the pain of switching IDEs. I
guess I'll find out...

I've done a diff and current git and svn HEAD agree. I've also done some
random checks of tags etc and all looks OK.

Next up I want to do a test commit. All, please don't commit to the repo
just yet - even if you see me making commits.

Thanks,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Rémy Maucherat]

On Tue, Feb 26, 2019 at 1:33 PM Mark Thomas  wrote:

> All,
>
> https://github.com/apache/tomcat
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>
> Tags:
> - one for each 7.0.x, 8.5.x and 9.0.x release
>
> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> version number where modifier is RC or M.
>
> The repository is probably read/write for all committers now but please
> refrain from making any changes until we confirm that all is well.
>
> If you have some time available now, please test this new repository and
> report and questions or concerns to this thread.
>
> Assuming no issues are discovered, I'd like to formally move over to git
> later today.
>

That looks quite good :)

Should we plan to all work with PRs for large changes ?

Rémy

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 13:10, Mark Thomas wrote:
> On 26/02/2019 12:45, Martin Grigorov wrote:



>> All seems to work.
>> I haven't received any email notifications though.
> 
> I'll check where notifications are being sent.

That should be fixed now.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Mark Thomas]

On 26/02/2019 12:45, Martin Grigorov wrote:
> Hi,
> 
> On Tue, Feb 26, 2019 at 2:33 PM Mark Thomas  wrote:
> 
>> All,
>>
>> https://github.com/apache/tomcat
>>
>> is now ready for testing.
>>
>> It should contain:
>> branches
>> - master (9.0.x)
>> - 8.5.x
>> - 7.0.x
>>
>> Tags:
>> - one for each 7.0.x, 8.5.x and 9.0.x release
>>
>> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
>> version number where modifier is RC or M.
>>
>> The repository is probably read/write for all committers now but please
>> refrain from making any changes until we confirm that all is well.
>>
>> If you have some time available now, please test this new repository and
>> report and questions or concerns to this thread.
>>
> 
> I've just created a new branch, committed an empty change and removed the
> branch.
> All seems to work.
> I haven't received any email notifications though.

I'll check where notifications are being sent.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration read for testing

[Martin Grigorov]

Hi,

On Tue, Feb 26, 2019 at 2:33 PM Mark Thomas  wrote:

> All,
>
> https://github.com/apache/tomcat
>
> is now ready for testing.
>
> It should contain:
> branches
> - master (9.0.x)
> - 8.5.x
> - 7.0.x
>
> Tags:
> - one for each 7.0.x, 8.5.x and 9.0.x release
>
> Tags have all been renamed to follow a a.b.c-MODIFIERn format for
> version number where modifier is RC or M.
>
> The repository is probably read/write for all committers now but please
> refrain from making any changes until we confirm that all is well.
>
> If you have some time available now, please test this new repository and
> report and questions or concerns to this thread.
>

I've just created a new branch, committed an empty change and removed the
branch.
All seems to work.
I haven't received any email notifications though.

Martin


>
> Assuming no issues are discovered, I'd like to formally move over to git
> later today.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Git migration: new branch/tag naming scheme

[Konstantin Kolinko]

пн, 18 февр. 2019 г. в 11:08, Emmanuel Bourg 
>
> Le 16/02/2019 à 16:09, Michael Osipov a écrit :
>
> > The given approach, for whatsoever reason, performs an uppercase and
> > replaces dots with underscores. This reduces readability, but also
> > requires people (esp. package maintainers) to perform sed(1) magic to
> > convert back and forth.
>
> I agree this is cumbersome, we are doing this kind of manipulation in
> Debian too to compare the version packaged with the latest upstream release.
>

1. What do we do with RC and milestone release tags, e.g.
TOMCAT_7_0_0_RC4, TOMCAT_9_0_0_M27?

9.0.0.M27, 9.0.0-M27, 9.0.0_M27, or the same with lowercase 'm'?

Historically,
Tomcat 9 used a dot "9.0.0.M27" in announcements and in filenames [1][2],
Tomcat 8 used a dash "8.0.0-RC10" in announcements and filenames [3][4] .
Tomcat 7 used a "-beta" suffix in filenames [5].

Different downstream packagers (e.g. Maven, RPM) may have different
rules regarding handling and sorting such names. The '-' symbol may be
special.

[1] http://tomcat.apache.org/oldnews-2016.html
[2] https://archive.apache.org/dist/tomcat/tomcat-9/
[3] http://tomcat.apache.org/oldnews-2013.html
[4] https://archive.apache.org/dist/tomcat/tomcat-8/
[5] https://archive.apache.org/dist/tomcat/tomcat-7/

My preference is to stick with the current historical format of tag
names (TOMCAT_) and let downstream deal with proper parsing and
formatting of these numbers.

> to perform sed(1) magic

2. The prefix "TOMCAT_x_y_" is fixed in a particular branch and has
known length. I had processed similar strings with 'cut' utility [6].
This can also be processed by parameters substitution in shell [7].
Though somebody may call that magic as well.

[6] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html
[7] 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02

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 migration: new branch/tag naming scheme

[Michael Osipov]

Am 2019-02-20 um 17:44 schrieb Mark Thomas:

On 20/02/2019 16:14, Igal Sapir wrote:

Michael,

On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov  wrote:


Am 2019-02-18 um 15:19 schrieb Igal Sapir:



I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.


tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in
development. This a common scheme in many many repos.
Where is the benefit keeping the prefix? Git autocompletion will stop at
"8.5." and you choose either 'x' or a patch release.



If I want to switch branches, which is more often than switching to a tag
in my case, I would simply start with 't' without having to go through the
tags.

Having to go through the tag options when I actually want to switch to a
branch is inefficient.

Don't get me wrong, I don't care much which ones have a 'tc' prefix
(branches) and which do not (tags), I just like that there is a difference
between branches and tags.


This got me thinking about how many key pressed would actually be
required for branches

Case A:
Branches: 7.0.x, 8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [7|8|m]
master then auto-completes
7.0.x and 8.5.x get to "7.0." and "8.5." respectively and need a further
"x" to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 3 for 7.0.x or 8.5.x

Case B:
Branches: tc7.0.x, tc8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [t|m]
master then auto-completes
7.0.x and 8.5.x both get to "tc" and need a further "7" or "8" and 
to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 4 for 7.0.x or 8.5.x


Of course there are complications to this:
- I suspect most developers will be using worktrees
- keypresses are probably less important than how the GUIs of our
   preferred tools handles this


In a GUI it will show how clearly what is a branch or a tag. There 
shouldn't be any  ambiguity.



I think this comes down to whether it is worth using a prefix (tc) to
(more clearly) differentiate release branches and tags in those places
where the two appear together.

To put it another way:

Is "9.0.5 vs tc9.0.x" clearer than "9.0.5 vs 9.0.x"? And if it is, do we
want that additional clarity?


Fo me, it looks inconsistent. "9.0.5 vs 9.0.x" clearly says that the 
former is a fixed version whereas the latter is a moving target in 9.0.


I'd clearly opt for simplicity.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Igal Sapir]

Mark,

On 2/20/2019 8:44 AM, Mark Thomas wrote:

On 20/02/2019 16:14, Igal Sapir wrote:

Michael,

On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov  wrote:


Am 2019-02-18 um 15:19 schrieb Igal Sapir:



I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.

tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in
development. This a common scheme in many many repos.
Where is the benefit keeping the prefix? Git autocompletion will stop at
"8.5." and you choose either 'x' or a patch release.


If I want to switch branches, which is more often than switching to a tag
in my case, I would simply start with 't' without having to go through the
tags.

Having to go through the tag options when I actually want to switch to a
branch is inefficient.

Don't get me wrong, I don't care much which ones have a 'tc' prefix
(branches) and which do not (tags), I just like that there is a difference
between branches and tags.

This got me thinking about how many key pressed would actually be
required for branches

Case A:
Branches: 7.0.x, 8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [7|8|m]
master then auto-completes
7.0.x and 8.5.x get to "7.0." and "8.5." respectively and need a further
"x" to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 3 for 7.0.x or 8.5.x

Case B:
Branches: tc7.0.x, tc8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [t|m]
master then auto-completes
7.0.x and 8.5.x both get to "tc" and need a further "7" or "8" and 
to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 4 for 7.0.x or 8.5.x


Of course there are complications to this:
- I suspect most developers will be using worktrees
- keypresses are probably less important than how the GUIs of our
   preferred tools handles this


I think this comes down to whether it is worth using a prefix (tc) to
(more clearly) differentiate release branches and tags in those places
where the two appear together.

To put it another way:

Is "9.0.5 vs tc9.0.x" clearer than "9.0.5 vs 9.0.x"? And if it is, do we
want that additional clarity?


I personally prefer and welcome that clarity, but TBH it's not a big 
deal either way.


I see myself mostly working on branches, and switching to tags only when 
I need to test a specific release.


Best,

Igal



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Mark Thomas]

On 20/02/2019 16:14, Igal Sapir wrote:
> Michael,
> 
> On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov  wrote:
> 
>> Am 2019-02-18 um 15:19 schrieb Igal Sapir:
>>> 
>>>
>>> I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
>>> "7.0.x").  If tags will only use the numeric versions then this will make
>>> it easy to differentiate between branches and tags.
>>
>> tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in
>> development. This a common scheme in many many repos.
>> Where is the benefit keeping the prefix? Git autocompletion will stop at
>> "8.5." and you choose either 'x' or a patch release.
>>
> 
> If I want to switch branches, which is more often than switching to a tag
> in my case, I would simply start with 't' without having to go through the
> tags.
> 
> Having to go through the tag options when I actually want to switch to a
> branch is inefficient.
> 
> Don't get me wrong, I don't care much which ones have a 'tc' prefix
> (branches) and which do not (tags), I just like that there is a difference
> between branches and tags.

This got me thinking about how many key pressed would actually be
required for branches

Case A:
Branches: 7.0.x, 8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [7|8|m]
master then auto-completes
7.0.x and 8.5.x get to "7.0." and "8.5." respectively and need a further
"x" to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 3 for 7.0.x or 8.5.x

Case B:
Branches: tc7.0.x, tc8.5.x, master
Tags: 7.0.11, 8.5.20, 9.0.12 etc.

git checkout [t|m]
master then auto-completes
7.0.x and 8.5.x both get to "tc" and need a further "7" or "8" and 
to complete.

So that makes (ignoring the "git checkout ") 2 key presses for master
and 4 for 7.0.x or 8.5.x


Of course there are complications to this:
- I suspect most developers will be using worktrees
- keypresses are probably less important than how the GUIs of our
  preferred tools handles this


I think this comes down to whether it is worth using a prefix (tc) to
(more clearly) differentiate release branches and tags in those places
where the two appear together.

To put it another way:

Is "9.0.5 vs tc9.0.x" clearer than "9.0.5 vs 9.0.x"? And if it is, do we
want that additional clarity?


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Igal Sapir]

Michael,

On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov  wrote:

> Am 2019-02-18 um 15:19 schrieb Igal Sapir:
> > 
> >
> > I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
> > "7.0.x").  If tags will only use the numeric versions then this will make
> > it easy to differentiate between branches and tags.
>
> tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in
> development. This a common scheme in many many repos.
> Where is the benefit keeping the prefix? Git autocompletion will stop at
> "8.5." and you choose either 'x' or a patch release.
>

If I want to switch branches, which is more often than switching to a tag
in my case, I would simply start with 't' without having to go through the
tags.

Having to go through the tag options when I actually want to switch to a
branch is inefficient.

Don't get me wrong, I don't care much which ones have a 'tc' prefix
(branches) and which do not (tags), I just like that there is a difference
between branches and tags.

Igal

Re: Git migration: new branch/tag naming scheme

[Michael Osipov]

Am 2019-02-18 um 15:19 schrieb Igal Sapir:

On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas  wrote:


On 18/02/2019 09:13, Rémy Maucherat wrote:

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov 

wrote:



Folks,

given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
naming scheme.

The given approach, for whatsoever reason, performs an uppercase and
replaces dots with underscores. This reduces readability, but also
requires people (esp. package maintainers) to perform sed(1) magic to
convert back and forth.

There are bascially two approaches I'd like to discuss:

Approch 1: It will reuse the branch name of the current major version,
excluding master. Thus, we will have the following prefixes: tomcat90-,
tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
released separately the prefix would be jdbc-pool-. The version itself
would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.

Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
would be autocompletion in Git CLI. I could simply say: "git checkout
tomcat85" or "git checkout tomcat85-" and grab the specific version
I want.

Approach 2: A simpler, less redundant approach would be naming the
branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
etc. The Git autocompletion will work here too.

I personally opt for approach 2 because it is consistent, concise and
removes redundancy on always used prefixes.



I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.


The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"



That's fine by me.




There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.



No good reason.  Based on the OP I thought that we are comparing to a more
verbose scheme like "tomcat-90-xxx" (without the standard "master" branch).

I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.


tc8.5 could also misread as 8.5 release. 8.5.x implies that this is in 
development. This a common scheme in many many repos.
Where is the benefit keeping the prefix? Git autocompletion will stop at 
"8.5." and you choose either 'x' or a patch release.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Michael Osipov]

Am 2019-02-18 um 11:03 schrieb Mark Thomas:

On 18/02/2019 09:13, Rémy Maucherat wrote:

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:


Folks,

given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
naming scheme.

The given approach, for whatsoever reason, performs an uppercase and
replaces dots with underscores. This reduces readability, but also
requires people (esp. package maintainers) to perform sed(1) magic to
convert back and forth.

There are bascially two approaches I'd like to discuss:

Approch 1: It will reuse the branch name of the current major version,
excluding master. Thus, we will have the following prefixes: tomcat90-,
tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
released separately the prefix would be jdbc-pool-. The version itself
would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.

Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
would be autocompletion in Git CLI. I could simply say: "git checkout
tomcat85" or "git checkout tomcat85-" and grab the specific version
I want.

Approach 2: A simpler, less redundant approach would be naming the
branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
etc. The Git autocompletion will work here too.

I personally opt for approach 2 because it is consistent, concise and
removes redundancy on always used prefixes.



I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.


The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"

There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.


The current proposal, community agreed proposal for tags is to continue
with the current naming scheme. Switching to using the version as-is
(9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
migration. If the as-is naming scheme makes it easier for downstream
users then that strikes me as a good reason to change it. Are there any
objections to doing so?


I'd be happy if we could clean that up..


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/18/19 05:03, Mark Thomas wrote:
> On 18/02/2019 09:13, Rémy Maucherat wrote:
>> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov
>>  wrote:
>> 
>>> Folks,
>>> 
>>> given that we are currently in the process of migrating to Git
>>> I'd like to propose a more readible and with the branch names
>>> consistent tag naming scheme.
>>> 
>>> The given approach, for whatsoever reason, performs an
>>> uppercase and replaces dots with underscores. This reduces
>>> readability, but also requires people (esp. package
>>> maintainers) to perform sed(1) magic to convert back and
>>> forth.
>>> 
>>> There are bascially two approaches I'd like to discuss:
>>> 
>>> Approch 1: It will reuse the branch name of the current major
>>> version, excluding master. Thus, we will have the following
>>> prefixes: tomcat90-, tomcat85-, and tomcat70-. Since JDBC Pool
>>> remains in place and if it is released separately the prefix
>>> would be jdbc-pool-. The version itself would remain as-is and
>>> simply appended, e.g., 8.5.40, 9.0.25, etc.
>>> 
>>> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another
>>> benefit would be autocompletion in Git CLI. I could simply say:
>>> "git checkout tomcat85" or "git checkout tomcat85-" and
>>> grab the specific version I want.
>>> 
>>> Approach 2: A simpler, less redundant approach would be naming
>>> the branches master, 7.0.x, 8.5.x, etc. and get rid of the
>>> "tomcat" prefix at all. The tags would simply be the versions
>>> as-is: 8.5.40, 9.0.25, etc. The Git autocompletion will work
>>> here too.
>>> 
>>> I personally opt for approach 2 because it is consistent,
>>> concise and removes redundancy on always used prefixes.
>>> 
>> 
>> I guess it's hard to argue against option 2.
>> 
>> The main downside is that it comes late and Mark already did the
>> work and lots of testing for his proposed plan.
> 
> The current, community agreed proposal for branch naming is
> "master, tc8.5 and tc7.0"
> 
> There were strong views on the branch naming but "master, 8.5.x
> and 7.0.x" would be consistent with those views. I'm not sure I see
> much difference between either approach. If there is a strong
> preference for one over the other - or a good reason to choose one
> over the other - please make those views known in the next few
> days.
> 
> 
> The current proposal, community agreed proposal for tags is to
> continue with the current naming scheme. Switching to using the
> version as-is (9.0.1, 9.0.2, etc) is doable. It is just a little
> more work during the migration. If the as-is naming scheme makes it
> easier for downstream users then that strikes me as a good reason
> to change it. Are there any objections to doing so?

No objections, here.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxrC9sACgkQHPApP6U8
pFiQ7g/9FwNkmK6aIGRCKIzeinQid1+umxHdOgobludzhnZcIObJKF9oALquyCgB
UivQfAU+Tcx1eoSwkKx7JDxq5MxkktfsKXzT9+L2eDfgMwyfaVjTtsq0Ia0Qmay6
OgDTspP95XZQlDoMhWNYS6zVqP/Yf4YIF6NxnA9ax+GGv6r4K6mED7oDbjHGXiq+
XqeFHibx0ynCai2L7S88UpIGiUWY70/l79+bZ3zOXfqmCRv4TotwuBoBh68RbYJB
A1x4VMs22OfuM9LF7K2kzAjtaEA4XNVn7sC1tYuwpr6LUx7gwlB1xB70F5oYiQlI
PhxYcSiFVnbiuROyU1cF1rOl6QuIQxhMYodABilEARrmoxk5vjG7f8ToOuUm0Wd1
yU02dt6B+rm3PHu5eFp5iRwHJiarYDFubO47Qwj0c+bkvn3R+u4XJ6CXMfV1j2SW
u7HjAjILU9iSAsVEIaYj04Ksv8A+6v6Czg4m/f8KWy+KX8nb50wfjfUiXfjdRB8m
saEOq03tjmlGfKipYPaNO3qUEP64S5EqJCyJj9acQ1ravd+8k1GteiUYuOWHFMzm
bNSAcb6YqKsqB//hSFRlIgsVTrr9/mx2FzhCzp/9a3RLzIsvA81Bxg6BHcJ91/cV
AVofdNE4X/WNsXoHDEx8FpgL/wCVbr3ODpt43SEv8f4XtsIrym0=
=gZ8p
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Igal Sapir]

On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas  wrote:

> On 18/02/2019 09:13, Rémy Maucherat wrote:
> > On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov 
> wrote:
> >
> >> Folks,
> >>
> >> given that we are currently in the process of migrating to Git I'd like
> >> to propose a more readible and with the branch names consistent tag
> >> naming scheme.
> >>
> >> The given approach, for whatsoever reason, performs an uppercase and
> >> replaces dots with underscores. This reduces readability, but also
> >> requires people (esp. package maintainers) to perform sed(1) magic to
> >> convert back and forth.
> >>
> >> There are bascially two approaches I'd like to discuss:
> >>
> >> Approch 1: It will reuse the branch name of the current major version,
> >> excluding master. Thus, we will have the following prefixes: tomcat90-,
> >> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
> >> released separately the prefix would be jdbc-pool-. The version itself
> >> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.
> >>
> >> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
> >> would be autocompletion in Git CLI. I could simply say: "git checkout
> >> tomcat85" or "git checkout tomcat85-" and grab the specific version
> >> I want.
> >>
> >> Approach 2: A simpler, less redundant approach would be naming the
> >> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
> >> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
> >> etc. The Git autocompletion will work here too.
> >>
> >> I personally opt for approach 2 because it is consistent, concise and
> >> removes redundancy on always used prefixes.
> >>
> >
> > I guess it's hard to argue against option 2.
> >
> > The main downside is that it comes late and Mark already did the work and
> > lots of testing for his proposed plan.
>
> The current, community agreed proposal for branch naming is "master,
> tc8.5 and tc7.0"
>

That's fine by me.


>
> There were strong views on the branch naming but "master, 8.5.x and
> 7.0.x" would be consistent with those views. I'm not sure I see much
> difference between either approach. If there is a strong preference for
> one over the other - or a good reason to choose one over the other -
> please make those views known in the next few days.
>

No good reason.  Based on the OP I thought that we are comparing to a more
verbose scheme like "tomcat-90-xxx" (without the standard "master" branch).

I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x").  If tags will only use the numeric versions then this will make
it easy to differentiate between branches and tags.



>
> The current proposal, community agreed proposal for tags is to continue
> with the current naming scheme. Switching to using the version as-is
> (9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
> migration. If the as-is naming scheme makes it easier for downstream
> users then that strikes me as a good reason to change it. Are there any
> objections to doing so?
>

Git tags are very lightweight, they are just pointers to other commits, so
if it's easier, we can do the migration as-is and then write some script to
generate new tags with the new naming convention, it shouldn't be too hard
IMO.  The old tags can remain or be removed at a later time.  They hardly
take any space.

Best,

Igal

Re: Git migration: new branch/tag naming scheme

[Mark Thomas]

On 18/02/2019 09:13, Rémy Maucherat wrote:
> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:
> 
>> Folks,
>>
>> given that we are currently in the process of migrating to Git I'd like
>> to propose a more readible and with the branch names consistent tag
>> naming scheme.
>>
>> The given approach, for whatsoever reason, performs an uppercase and
>> replaces dots with underscores. This reduces readability, but also
>> requires people (esp. package maintainers) to perform sed(1) magic to
>> convert back and forth.
>>
>> There are bascially two approaches I'd like to discuss:
>>
>> Approch 1: It will reuse the branch name of the current major version,
>> excluding master. Thus, we will have the following prefixes: tomcat90-,
>> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
>> released separately the prefix would be jdbc-pool-. The version itself
>> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.
>>
>> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
>> would be autocompletion in Git CLI. I could simply say: "git checkout
>> tomcat85" or "git checkout tomcat85-" and grab the specific version
>> I want.
>>
>> Approach 2: A simpler, less redundant approach would be naming the
>> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
>> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
>> etc. The Git autocompletion will work here too.
>>
>> I personally opt for approach 2 because it is consistent, concise and
>> removes redundancy on always used prefixes.
>>
> 
> I guess it's hard to argue against option 2.
> 
> The main downside is that it comes late and Mark already did the work and
> lots of testing for his proposed plan.

The current, community agreed proposal for branch naming is "master,
tc8.5 and tc7.0"

There were strong views on the branch naming but "master, 8.5.x and
7.0.x" would be consistent with those views. I'm not sure I see much
difference between either approach. If there is a strong preference for
one over the other - or a good reason to choose one over the other -
please make those views known in the next few days.


The current proposal, community agreed proposal for tags is to continue
with the current naming scheme. Switching to using the version as-is
(9.0.1, 9.0.2, etc) is doable. It is just a little more work during the
migration. If the as-is naming scheme makes it easier for downstream
users then that strikes me as a good reason to change it. Are there any
objections to doing so?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration: new branch/tag naming scheme

[Rémy Maucherat]

On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov  wrote:

> Folks,
>
> given that we are currently in the process of migrating to Git I'd like
> to propose a more readible and with the branch names consistent tag
> naming scheme.
>
> The given approach, for whatsoever reason, performs an uppercase and
> replaces dots with underscores. This reduces readability, but also
> requires people (esp. package maintainers) to perform sed(1) magic to
> convert back and forth.
>
> There are bascially two approaches I'd like to discuss:
>
> Approch 1: It will reuse the branch name of the current major version,
> excluding master. Thus, we will have the following prefixes: tomcat90-,
> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
> released separately the prefix would be jdbc-pool-. The version itself
> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.
>
> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
> would be autocompletion in Git CLI. I could simply say: "git checkout
> tomcat85" or "git checkout tomcat85-" and grab the specific version
> I want.
>
> Approach 2: A simpler, less redundant approach would be naming the
> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
> etc. The Git autocompletion will work here too.
>
> I personally opt for approach 2 because it is consistent, concise and
> removes redundancy on always used prefixes.
>

I guess it's hard to argue against option 2.

The main downside is that it comes late and Mark already did the work and
lots of testing for his proposed plan.

Rémy


>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Git migration: new branch/tag naming scheme

[Emmanuel Bourg]

Le 16/02/2019 à 16:09, Michael Osipov a écrit :

> The given approach, for whatsoever reason, performs an uppercase and
> replaces dots with underscores. This reduces readability, but also
> requires people (esp. package maintainers) to perform sed(1) magic to
> convert back and forth.

I agree this is cumbersome, we are doing this kind of manipulation in
Debian too to compare the version packaged with the latest upstream release.

If I remember well this convention is inherited from the CVS era, dots
were not allowed in tag names and thus commonly replaced by underscores
or dashes.


> Approch 1: It will reuse the branch name of the current major version,
> excluding master. Thus, we will have the following prefixes: tomcat90-,
> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
> released separately the prefix would be jdbc-pool-. The version itself
> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.

-0

> Approach 2: A simpler, less redundant approach would be naming the
> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
> etc. The Git autocompletion will work here too.

+1

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration - Timing

[Igal Sapir]

On Mon, Feb 11, 2019 at 6:51 AM Mark Thomas  wrote:

> All,
>
> I'd like to propose that we make the move from svn to git for Tomcat
> 7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.
>

This is very exciting.  I have been using Git for some time now, and only
started using Subversion with the Tomcat project, and found it to be rather
difficult to use in comparison.  I was also locked out of the Apache
networks at some point when I tried to download the whole SVN repo.

Incidentally, I was traveling last week (@Remy, you have a beautiful
country) and my primary reading material for the long flights was about
Subversion.  I'm quite happy that I won't need to put my newly acquired
knowledge to use.

What about the "site" branch?  I don't see it mentioned anywhere and I
think that it's important to migrate it to Git as well.

Best,

Igal



> The proposed approach is documented here:
> https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration
>
> I anticipate that the repositories will be read only for a couple of hours.
>
> I also anticipate that the CI systems - particularly Gump - will take up
> to a day to switch over and iron out any problems.
>
> Any objections?
>
> If not, I'll start a formal VOTE.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Git migration: new branch/tag naming scheme

[Igal Sapir]

Michael,

On Sat, Feb 16, 2019 at 7:09 AM Michael Osipov  wrote:

> 
>
> There are bascially two approaches I'd like to discuss:
>
> Approch 1: It will reuse the branch name of the current major version,
> excluding master. Thus, we will have the following prefixes: tomcat90-,
> tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is
> released separately the prefix would be jdbc-pool-. The version itself
> would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc.
>
> Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit
> would be autocompletion in Git CLI. I could simply say: "git checkout
> tomcat85" or "git checkout tomcat85-" and grab the specific version
> I want.
>
> Approach 2: A simpler, less redundant approach would be naming the
> branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix
> at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25,
> etc. The Git autocompletion will work here too.
>
> I personally opt for approach 2 because it is consistent, concise and
> removes redundancy on always used prefixes.
>

I also prefer the 2nd option.  Working with a "master" branch on Git is
much more "standard", and I'm always in favor of removing boilerplate that
is repeated over and over.

Best,

Igal



>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Git migration - Timing

[Michael Osipov]

Am 2019-02-16 um 14:46 schrieb Mark Thomas:

On 16/02/2019 13:39, Michael Osipov wrote:

Am 2019-02-11 um 15:51 schrieb Mark Thomas:

All,

I'd like to propose that we make the move from svn to git for Tomcat
7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.

The proposed approach is documented here:
https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration

I anticipate that the repositories will be read only for a couple of
hours.

I also anticipate that the CI systems - particularly Gump - will take up
to a day to switch over and iron out any problems.

Any objections?


Hi Mark,

thanks for bearing with me. I was now finally able to look at the
proposal. As far as I understand there wil be a single repo for the
entire code base and everything will happen in branches.

Here are my comments:

1. You have set up branches: master, tomcat70, tomcat85, etc, but the
document talks about "Branch names. master, tc8.5, tc8.0, tc7.0 etc"
that seems to be inconsistent.


The demo was set up before the branch names were agreed.


2. What will happens with Tomcat JDBC Pool? Will in remain in the
Subversion repo or will it move to tomcat-jdbc-pool.git? The code does
not change that offen that justifies a tandem release with Tomcat.


It will remain part of the repo for each Tomcat version - as it is now.


3. Why do you bother to import Tomcat 8.0? It is EOL, leave it in
Subversion. Do you plan to perform any futher merge here?


The demo was set up before 8.0.x was made EOL. There are no plans to
move 8.0.c to git.


4. Can we *please* have a readible tag name scheme?! I simply don't
understand why people uppercase everything and replace dots with
underscores. That's just ugly. Consistent tag names would be
"{branch-name}-{version}" for the mono repo. E.g, tomcat85-8.5.40, or
tomcat70-7.0.95. This would heavily reduce sed(1) magic for package
maintainers and improve readability.


The community has not expressed a desire to change the naming scheme.
You are, of course, free to start such a discussion on dev@.


5. I assume that mod_jk, native and friends will remain in the
Subversion repo?


Yes.


6. I don't see in the wiki page an agreement on a good/wellknown Git
commit message scheme: "BZ #123: \n\n"


No such convention exists for subversion. The community has not
expressed a desire to introduce one with the move to git. Again, you are
free to start a discussion on dev@


Thanks for the quick response. I will start the approapriate discussions!

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration - Timing

[Mark Thomas]

On 16/02/2019 13:39, Michael Osipov wrote:
> Am 2019-02-11 um 15:51 schrieb Mark Thomas:
>> All,
>>
>> I'd like to propose that we make the move from svn to git for Tomcat
>> 7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.
>>
>> The proposed approach is documented here:
>> https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration
>>
>> I anticipate that the repositories will be read only for a couple of
>> hours.
>>
>> I also anticipate that the CI systems - particularly Gump - will take up
>> to a day to switch over and iron out any problems.
>>
>> Any objections?
> 
> Hi Mark,
> 
> thanks for bearing with me. I was now finally able to look at the
> proposal. As far as I understand there wil be a single repo for the
> entire code base and everything will happen in branches.
> 
> Here are my comments:
> 
> 1. You have set up branches: master, tomcat70, tomcat85, etc, but the
> document talks about "Branch names. master, tc8.5, tc8.0, tc7.0 etc"
> that seems to be inconsistent.

The demo was set up before the branch names were agreed.

> 2. What will happens with Tomcat JDBC Pool? Will in remain in the
> Subversion repo or will it move to tomcat-jdbc-pool.git? The code does
> not change that offen that justifies a tandem release with Tomcat.

It will remain part of the repo for each Tomcat version - as it is now.

> 3. Why do you bother to import Tomcat 8.0? It is EOL, leave it in
> Subversion. Do you plan to perform any futher merge here?

The demo was set up before 8.0.x was made EOL. There are no plans to
move 8.0.c to git.

> 4. Can we *please* have a readible tag name scheme?! I simply don't
> understand why people uppercase everything and replace dots with
> underscores. That's just ugly. Consistent tag names would be
> "{branch-name}-{version}" for the mono repo. E.g, tomcat85-8.5.40, or
> tomcat70-7.0.95. This would heavily reduce sed(1) magic for package
> maintainers and improve readability.

The community has not expressed a desire to change the naming scheme.
You are, of course, free to start such a discussion on dev@.

> 5. I assume that mod_jk, native and friends will remain in the
> Subversion repo?

Yes.

> 6. I don't see in the wiki page an agreement on a good/wellknown Git
> commit message scheme: "BZ #123: \n\n"

No such convention exists for subversion. The community has not
expressed a desire to introduce one with the move to git. Again, you are
free to start a discussion on dev@

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration - Timing

[Michael Osipov]

Am 2019-02-11 um 15:51 schrieb Mark Thomas:

All,

I'd like to propose that we make the move from svn to git for Tomcat
7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.

The proposed approach is documented here:
https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration

I anticipate that the repositories will be read only for a couple of hours.

I also anticipate that the CI systems - particularly Gump - will take up
to a day to switch over and iron out any problems.

Any objections?


Hi Mark,

thanks for bearing with me. I was now finally able to look at the 
proposal. As far as I understand there wil be a single repo for the 
entire code base and everything will happen in branches.


Here are my comments:

1. You have set up branches: master, tomcat70, tomcat85, etc, but the 
document talks about "Branch names. master, tc8.5, tc8.0, tc7.0 etc" 
that seems to be inconsistent.
2. What will happens with Tomcat JDBC Pool? Will in remain in the 
Subversion repo or will it move to tomcat-jdbc-pool.git? The code does 
not change that offen that justifies a tandem release with Tomcat.
3. Why do you bother to import Tomcat 8.0? It is EOL, leave it in 
Subversion. Do you plan to perform any futher merge here?
4. Can we *please* have a readible tag name scheme?! I simply don't 
understand why people uppercase everything and replace dots with 
underscores. That's just ugly. Consistent tag names would be 
"{branch-name}-{version}" for the mono repo. E.g, tomcat85-8.5.40, or 
tomcat70-7.0.95. This would heavily reduce sed(1) magic for package 
maintainers and improve readability.
5. I assume that mod_jk, native and friends will remain in the 
Subversion repo?
6. I don't see in the wiki page an agreement on a good/wellknown Git 
commit message scheme: "BZ #123: \n\n"


Regards,

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Re: Git migration - Timing

[Michael Osipov]

> On 11/02/2019 19:57, Michael Osipov wrote:
> >> All,
> >>
> >> I'd like to propose that we make the move from svn to git for Tomcat
> >> 7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.
> >>
> >> The proposed approach is documented here:
> >> https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration
> >>
> >> I anticipate that the repositories will be read only for a couple of hours.
> >>
> >> I also anticipate that the CI systems - particularly Gump - will take up
> >> to a day to switch over and iron out any problems.
> >>
> >> Any objections?
> >>
> >> If not, I'll start a formal VOTE.
> > 
> > Can you leave me a few more days? I'd like to review the wiki page and add 
> > some propsals.
> 
> What sort of proposals?
> 
> Each of the issues has been discussed and the approach agreed within the
> community - on this list - over a period of many months.
> 
> Unless there is a show-stopper issue that has been missed in the
> discussions to date, I really do think it is time to move forward with
> the actual migration.

I completely missed that discussion, truly my fault.
It maybe nothing special I'd object or maybe nothing at all.
At Maven TLP we have migrated tens of repos, so we gained some experience here.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration - Timing

[Mark Thomas]

On 11/02/2019 19:57, Michael Osipov wrote:
>> All,
>>
>> I'd like to propose that we make the move from svn to git for Tomcat
>> 7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.
>>
>> The proposed approach is documented here:
>> https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration
>>
>> I anticipate that the repositories will be read only for a couple of hours.
>>
>> I also anticipate that the CI systems - particularly Gump - will take up
>> to a day to switch over and iron out any problems.
>>
>> Any objections?
>>
>> If not, I'll start a formal VOTE.
> 
> Can you leave me a few more days? I'd like to review the wiki page and add 
> some propsals.

What sort of proposals?

Each of the issues has been discussed and the approach agreed within the
community - on this list - over a period of many months.

Unless there is a show-stopper issue that has been missed in the
discussions to date, I really do think it is time to move forward with
the actual migration.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git migration - Timing

[Michael Osipov]

> All,
> 
> I'd like to propose that we make the move from svn to git for Tomcat
> 7.0.x, 8.5.x and 9.0.x as soon as the next 7.0.x release is complete.
> 
> The proposed approach is documented here:
> https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration
> 
> I anticipate that the repositories will be read only for a couple of hours.
> 
> I also anticipate that the CI systems - particularly Gump - will take up
> to a day to switch over and iron out any problems.
> 
> Any objections?
> 
> If not, I'll start a formal VOTE.

Can you leave me a few more days? I'd like to review the wiki page and add some 
propsals.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Documentation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/27/18 16:42, Mark Thomas wrote:
> We refer to svn in various places. Main web site, docs,
> BUILDING.txt etc.
> 
> The issue is when do we update the various docs. The main website
> we can update whenever, but the version specific docs normally only
> get updated when we do a release.
> 
> My suggested solution is to do the migration and once we are happy
> that the git repo is correct and we formally make it the master
> then we: - update the main web site ASAP - [ANNOUNCE] email to the
> community - Release 9.0.x, 8.5.x and 7.0.x ASAP with updated docs
> that refer to git rather than svn.
> 
> An added benefit is going through the release process soon after
> the migration should highlight any issues (I'm not expecting any)
> quickly.

Shall we do a special doc-only release with a short voting window? I'm
sure if we schedule it, we could do a vote in a few hours and push it
out immediately, rather than waiting the traditional 72 hours.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluFUp0ACgkQHPApP6U8
pFgphBAApks0G+ReWP5XsPIXawWXiO0H/gUzdeAa1dR/JgRY+xpiBgsKkHtqnv86
+ZMCRQr9uvHDuqjEHFlmvaZSKCo18M6TniCcI1mB72TqbGoON6zj/z+fdA1qq6ur
4j24GbebudUYN6uf8RDyqEBqtsfPE33AyADbtyuLrl5fLZ1z0uRNqiXdpNEQ5fpQ
0efOfQoRZ0krhmFNjqDFS8XlCZNHDSYHcXeC1s0OpwE2TVL+l+SBK5ExwtKleQuz
xes98wJSiydsnN9mkNlYoMxh3YbeHleuuO5p7jywvcERj5R7QIVv1dyQP6QnMwyj
zV/jKxvTO8Q+H3heiLAGteKWCKPyKTTgBC+B6OhBP1CkwAK7MCQNLiLio47Bxw6a
IU8RVpSgpk6vOG0e/8XsvnoAhCko+rsqWlDYcR8T7jyv5y/+jhMhp3MDz9DD5q1L
hl2GmvG36ky29UNTH7v/GnqhjeduL1bxPWWIH0QC5j6Zeh13pK7mdP/H2JxohfIg
ZHxnocdJcKrgRmFaoGDUVgBS8Bl232hq16VS8HOjSmaJbAfjxomijHoIVroW2z5q
Ar34Mft9RiZquHSqZrQdMUpukPbS5QkHKGT4gwm+gBkwcQUuAuwWJ7ek9+29CHfQ
UXarViaPRttj8G8pMbeqfuYLxONvp3TStkx9KPqz2XMVWM0jt7Y=
=kifR
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Developer process

[Mark Thomas]

On 31/05/18 19:16, Igal Sapir wrote:
> On 5/31/2018 3:00 AM, Mark Thomas wrote:
>> Hi,
>>
>> The next issue to resolve for the Git migration is developer process.
>>
>> Note that this does not cover branch names, merge strategy etc. This is
>> issue is about the options available for developers to organise their
>> local development environment. The key question is how to efficiently
>> switch between trunk, 8.5.x and 7.0.x.
>>
>> To some extent this will be personal preference. However, it would be
>> useful to have some recommendations to give folks a starting point.
>>
>> Options discussed previously include:
>> - multiple clones
>> - git worktree
> According to this blog post [1] Git Worktrees are a better solution.  It
> looks like Worktrees were added in order to address the shortfalls of
> maintaining multiple clones.
> 
> There is a warning, however, about using Worktrees on repos that contain
> submodules [2], and I don't know if that applies to the Tomcat repos or
> not, so that's something to look out for.

It has been a while. I'm going to add these two links to the migration
notes on the wiki. Googling "git worktree" returns a bunch of other
posts as well.

Onwards with the migration...

Mark

> 
> Igal
> 
> [1]
> https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/
> 
> [2]
> https://blog.github.com/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/
> 
> 
> 
> 
> -
> 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: [Git migration] Developer process

[Igal Sapir]

On 5/31/2018 3:00 AM, Mark Thomas wrote:

Hi,

The next issue to resolve for the Git migration is developer process.

Note that this does not cover branch names, merge strategy etc. This is
issue is about the options available for developers to organise their
local development environment. The key question is how to efficiently
switch between trunk, 8.5.x and 7.0.x.

To some extent this will be personal preference. However, it would be
useful to have some recommendations to give folks a starting point.

Options discussed previously include:
- multiple clones
- git worktree
According to this blog post [1] Git Worktrees are a better solution.  It 
looks like Worktrees were added in order to address the shortfalls of 
maintaining multiple clones.


There is a warning, however, about using Worktrees on repos that contain 
submodules [2], and I don't know if that applies to the Tomcat repos or 
not, so that's something to look out for.


Igal

[1] 
https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/
[2] 
https://blog.github.com/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Old git repositories

[Coty Sutherland]

On Mon, May 21, 2018 at 3:57 PM, Mark Thomas  wrote:

> On 04/05/18 10:22, Konstantin Kolinko wrote:
> > 2018-04-30 23:48 GMT+03:00 Mark Thomas :
> >> The current plan is to merge all of the existing branches into a single
> >> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
> >> currently used for the svn mirror for trunk only.
> >>
> >> This raises the question what to do with:
> >> apache/tomcat7
> >> apache/tomcat8
> >> apache/tomcat85
> >>
> >> I think there are two options:
> >>
> >> 1. Retain them but make them read-only
> >>
> >> 2. Delete them
> >>
> >> Suggestions for other options welcome.
> >>
> >> I'm actually leaning towards deleting them. [...]
> >
> > Option 3. Keep repository, but replace it with some README.md
> > with an instruction on where to look for the code.
> >
> >
> > A problem that I just stumbled upon:
> > See comment #17 in
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=43925
> >
> > That comment moved discussion from Bugzilla into PR in tomcat70.
> > If tomcat70 git repository is deleted, that PR and discussion in it
> > will be lost.
>
> The discussion should have been copied to the dev@ list. Maybe that
> isn't setup properly.
>
> There are only a very small number if issues like this. We can always
> manually copy content to the mailing list and/or Bugzilla to keep a copy.
>
> Given the general preference for deleting them, my proposal is a
> combination of all of the above which is.
>
> Make them read only. Review to ensure we have everything. Copy across
> anything we haven't got on list or in Bugzilla to the list/Bugzilla as
> appropriate. Then delete them.
>
> Thoughts?
>

+1, sounds good to me.


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [Git migration] Old git repositories

[Mark Thomas]

On 04/05/18 10:22, Konstantin Kolinko wrote:
> 2018-04-30 23:48 GMT+03:00 Mark Thomas :
>> The current plan is to merge all of the existing branches into a single
>> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
>> currently used for the svn mirror for trunk only.
>>
>> This raises the question what to do with:
>> apache/tomcat7
>> apache/tomcat8
>> apache/tomcat85
>>
>> I think there are two options:
>>
>> 1. Retain them but make them read-only
>>
>> 2. Delete them
>>
>> Suggestions for other options welcome.
>>
>> I'm actually leaning towards deleting them. [...]
> 
> Option 3. Keep repository, but replace it with some README.md
> with an instruction on where to look for the code.
> 
> 
> A problem that I just stumbled upon:
> See comment #17 in
> https://bz.apache.org/bugzilla/show_bug.cgi?id=43925
> 
> That comment moved discussion from Bugzilla into PR in tomcat70.
> If tomcat70 git repository is deleted, that PR and discussion in it
> will be lost.

The discussion should have been copied to the dev@ list. Maybe that
isn't setup properly.

There are only a very small number if issues like this. We can always
manually copy content to the mailing list and/or Bugzilla to keep a copy.

Given the general preference for deleting them, my proposal is a
combination of all of the above which is.

Make them read only. Review to ensure we have everything. Copy across
anything we haven't got on list or in Bugzilla to the list/Bugzilla as
appropriate. Then delete them.

Thoughts?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Old git repositories

[Konstantin Kolinko]

2018-04-30 23:48 GMT+03:00 Mark Thomas :
> The current plan is to merge all of the existing branches into a single
> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
> currently used for the svn mirror for trunk only.
>
> This raises the question what to do with:
> apache/tomcat7
> apache/tomcat8
> apache/tomcat85
>
> I think there are two options:
>
> 1. Retain them but make them read-only
>
> 2. Delete them
>
> Suggestions for other options welcome.
>
> I'm actually leaning towards deleting them. [...]

Option 3. Keep repository, but replace it with some README.md
with an instruction on where to look for the code.


A problem that I just stumbled upon:
See comment #17 in
https://bz.apache.org/bugzilla/show_bug.cgi?id=43925

That comment moved discussion from Bugzilla into PR in tomcat70.
If tomcat70 git repository is deleted, that PR and discussion in it
will be lost.


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 migration] Old git repositories

[Violeta Georgieva]

2018-04-30 16:48 GMT-04:00 Mark Thomas :
>
> The current plan is to merge all of the existing branches into a single
> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
> currently used for the svn mirror for trunk only.
>
> This raises the question what to do with:
> apache/tomcat7
> apache/tomcat8
> apache/tomcat85
>
> I think there are two options:
>
> 1. Retain them but make them read-only
>
> 2. Delete them

+1 delete them

Regards,
Violeta

> Suggestions for other options welcome.
>
> I'm actually leaning towards deleting them. My reasoning is that we
> deleted apache/tomcat55 and apache/tomcat6 when those releases reached
> EOL and no-one complained. As far as I recall, no-one even mentioned the
> deletions on list. Therefore, I'd be happy to delete those mirrors just
> as soon as apache/tomcat was up and running.
>
> Mark
>
> P.S. Don't forget that apache/tomcat will become writeable as part of
> the migration and will sync with gitbox.apache.org in a dual master
> configuration
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

Re: [Git migration] Old git repositories

[Huxing Zhang]

+1 for deleting them.

On Tue, May 1, 2018 at 5:36 AM, Coty Sutherland  wrote:
> On Mon, Apr 30, 2018, 16:48 Mark Thomas  wrote:
>
>> The current plan is to merge all of the existing branches into a single
>> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
>> currently used for the svn mirror for trunk only.
>>
>> This raises the question what to do with:
>> apache/tomcat7
>> apache/tomcat8
>> apache/tomcat85
>>
>> I think there are two options:
>>
>> 1. Retain them but make them read-only
>>
>> 2. Delete them
>>
>> Suggestions for other options welcome.
>>
>> I'm actually leaning towards deleting them. My reasoning is that we
>> deleted apache/tomcat55 and apache/tomcat6 when those releases reached
>> EOL and no-one complained. As far as I recall, no-one even mentioned the
>> deletions on list. Therefore, I'd be happy to delete those mirrors just
>> as soon as apache/tomcat was up and running.
>>
>
> I don't see a reason for keeping them so I'm +1 for deleting them.
>
>
>> Mark
>>
>> P.S. Don't forget that apache/tomcat will become writeable as part of
>> the migration and will sync with gitbox.apache.org in a dual master
>> configuration
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>



-- 
Best Regards！
Huxing

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Old git repositories

[Coty Sutherland]

On Mon, Apr 30, 2018, 16:48 Mark Thomas  wrote:

> The current plan is to merge all of the existing branches into a single
> Git repo. This will be mirrored at GitHub under apache/tomcat. This is
> currently used for the svn mirror for trunk only.
>
> This raises the question what to do with:
> apache/tomcat7
> apache/tomcat8
> apache/tomcat85
>
> I think there are two options:
>
> 1. Retain them but make them read-only
>
> 2. Delete them
>
> Suggestions for other options welcome.
>
> I'm actually leaning towards deleting them. My reasoning is that we
> deleted apache/tomcat55 and apache/tomcat6 when those releases reached
> EOL and no-one complained. As far as I recall, no-one even mentioned the
> deletions on list. Therefore, I'd be happy to delete those mirrors just
> as soon as apache/tomcat was up and running.
>

I don't see a reason for keeping them so I'm +1 for deleting them.


> Mark
>
> P.S. Don't forget that apache/tomcat will become writeable as part of
> the migration and will sync with gitbox.apache.org in a dual master
> configuration
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [Git migration] Commit message format

[Mark Thomas]

On 09/04/18 09:26, Mark Thomas wrote:
> On 21/03/18 13:00, Coty Sutherland wrote:
>> On Tue, Mar 20, 2018 at 4:07 PM, Mark Thomas  wrote:



>>> Having seen some of the messages for the tomcat-training repo what are
>>> people's thoughts?
>>
>> I have a couple small things.
>>
>> 1) The third block's formatting looks weird on my end. Example:
>>
>> "The following commit(s) were added to refs/heads/master by this push:
>>  new b13e925  First draft of logging module
>> b13e925 is described below"
>>
>> I'm not sure the first few lines are necessary (the automated message
>> bit and repository link), so they could be removed/cleaned up.
> 
> This is a common / standard format used across all ASF git repos. I
> suspect there are usage styles (pushes of a large number of commits)
> where this makes more sense.
> 
>> 2) Can we add a link to the commit somehow so that it closer resembles
>> the svn commit emails?
> 
> I think we can ask infra for this. Is this a blocker for us to migrate?

Infra pointed me towards this file:
https://github.com/apache/infrastructure-puppet/blob/deployment/modules/gitbox/files/asfgit/git_multimail.py

and indicated that they would be receptive to patches.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Commit message format

[Mark Thomas]

On 21/03/18 13:00, Coty Sutherland wrote:
> On Tue, Mar 20, 2018 at 4:07 PM, Mark Thomas  wrote:
>> On 21/02/18 16:48, Mark Thomas wrote:
>>> On 21/02/18 16:10, Rainer Jung wrote:
 Am 21.02.2018 um 16:53 schrieb Mark Thomas:
> The next issue on the list is the format of commit messages.
>
> The commit messages we are seeing for the tomcat-training repository
> have the same format as the commit message for the main tomcat repo will
> have.
>
> Does anyone have any concerns regarding the format?

 Would we be able to determine the branch from the subject line, e.g.
 would it be part of what is written between the square brackets? I
 personally find it very convenient to be able to easily filter commit
 mails by branch.
>>>
>>> Where there are new files described in subsequent commits, those commits
>>> don't have a branch in the subject. You can see how this works in
>>> practice on comm...@infra.apache.org
>>
>> Coming back to this.
>>
>> Having seen some of the messages for the tomcat-training repo what are
>> people's thoughts?
> 
> I have a couple small things.
> 
> 1) The third block's formatting looks weird on my end. Example:
> 
> "The following commit(s) were added to refs/heads/master by this push:
>  new b13e925  First draft of logging module
> b13e925 is described below"
> 
> I'm not sure the first few lines are necessary (the automated message
> bit and repository link), so they could be removed/cleaned up.

This is a common / standard format used across all ASF git repos. I
suspect there are usage styles (pushes of a large number of commits)
where this makes more sense.

> 2) Can we add a link to the commit somehow so that it closer resembles
> the svn commit emails?

I think we can ask infra for this. Is this a blocker for us to migrate?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Commit message format

[Coty Sutherland]

On Tue, Mar 20, 2018 at 4:07 PM, Mark Thomas  wrote:
> On 21/02/18 16:48, Mark Thomas wrote:
>> On 21/02/18 16:10, Rainer Jung wrote:
>>> Am 21.02.2018 um 16:53 schrieb Mark Thomas:
 The next issue on the list is the format of commit messages.

 The commit messages we are seeing for the tomcat-training repository
 have the same format as the commit message for the main tomcat repo will
 have.

 Does anyone have any concerns regarding the format?
>>>
>>> Would we be able to determine the branch from the subject line, e.g.
>>> would it be part of what is written between the square brackets? I
>>> personally find it very convenient to be able to easily filter commit
>>> mails by branch.
>>
>> Where there are new files described in subsequent commits, those commits
>> don't have a branch in the subject. You can see how this works in
>> practice on comm...@infra.apache.org
>
> Coming back to this.
>
> Having seen some of the messages for the tomcat-training repo what are
> people's thoughts?

I have a couple small things.

1) The third block's formatting looks weird on my end. Example:

"The following commit(s) were added to refs/heads/master by this push:
 new b13e925  First draft of logging module
b13e925 is described below"

I'm not sure the first few lines are necessary (the automated message
bit and repository link), so they could be removed/cleaned up.

2) Can we add a link to the commit somehow so that it closer resembles
the svn commit emails?

Other than those things, I think it's OK.

>
> Mark
>
> -
> 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: [Git migration] Commit message format

[Mark Thomas]

On 21/02/18 16:48, Mark Thomas wrote:
> On 21/02/18 16:10, Rainer Jung wrote:
>> Am 21.02.2018 um 16:53 schrieb Mark Thomas:
>>> The next issue on the list is the format of commit messages.
>>>
>>> The commit messages we are seeing for the tomcat-training repository
>>> have the same format as the commit message for the main tomcat repo will
>>> have.
>>>
>>> Does anyone have any concerns regarding the format?
>>
>> Would we be able to determine the branch from the subject line, e.g.
>> would it be part of what is written between the square brackets? I
>> personally find it very convenient to be able to easily filter commit
>> mails by branch.
> 
> Where there are new files described in subsequent commits, those commits
> don't have a branch in the subject. You can see how this works in
> practice on comm...@infra.apache.org

Coming back to this.

Having seen some of the messages for the tomcat-training repo what are
people's thoughts?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Commit message format

[Mark Thomas]

On 21/02/18 16:10, Rainer Jung wrote:
> Am 21.02.2018 um 16:53 schrieb Mark Thomas:
>> The next issue on the list is the format of commit messages.
>>
>> The commit messages we are seeing for the tomcat-training repository
>> have the same format as the commit message for the main tomcat repo will
>> have.
>>
>> Does anyone have any concerns regarding the format?
> 
> Would we be able to determine the branch from the subject line, e.g.
> would it be part of what is written between the square brackets? I
> personally find it very convenient to be able to easily filter commit
> mails by branch.

Where there are new files described in subsequent commits, those commits
don't have a branch in the subject. You can see how this works in
practice on comm...@infra.apache.org

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Commit message format

[Rainer Jung]

Am 21.02.2018 um 16:53 schrieb Mark Thomas:

The next issue on the list is the format of commit messages.

The commit messages we are seeing for the tomcat-training repository
have the same format as the commit message for the main tomcat repo will
have.

Does anyone have any concerns regarding the format?


Would we be able to determine the branch from the subject line, e.g. 
would it be part of what is written between the square brackets? I 
personally find it very convenient to be able to easily filter commit 
mails by branch.


Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Commit message format

[Rémy Maucherat]

On Wed, Feb 21, 2018 at 4:53 PM, Mark Thomas  wrote:

> The next issue on the list is the format of commit messages.
>
> The commit messages we are seeing for the tomcat-training repository
> have the same format as the commit message for the main tomcat repo will
> have.
>
> Does anyone have any concerns regarding the format?
>
> I'm too used to the old one ;)
So I guess it's fine, the good thing is that I suppose it'll get rid of the
revision merge info.

Rémy

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Mark Thomas]

On 20/02/18 13:19, Emmanuel Bourg wrote:
> Le 20/02/2018 à 13:42, Mark Thomas a écrit :
> 
>> But they'd be in the source bundle. Isn't that sufficient to build off-line?
> 
> Yes it is, and that's fine for Debian (Although currently the Debian
> package doesn't use the source bundle but checks out from SVN, but this
> can be changed).
> 
>> I'm not clear on what Debian needs here. There clearer you can be, the
>> more likely we are to pick a solution that works for Debian as well as
>> Tomcat.
> 
> I see two options:
> 1) Turn Tomcat Native into a "standard" dependency (bundled in its own
> jar downloaded from Maven Central)
> 2) Add an independent Ant target that downloads the Tomcat Native source
> files into the Tomcat source tree, the commit hash or tag being
> specified in a build property.

OK. I think 2 is the way to go here. I'll update the wiki accordingly.

Thanks for all the feedback on this issue.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Emmanuel Bourg]

Le 20/02/2018 à 13:42, Mark Thomas a écrit :

> But they'd be in the source bundle. Isn't that sufficient to build off-line?

Yes it is, and that's fine for Debian (Although currently the Debian
package doesn't use the source bundle but checks out from SVN, but this
can be changed).

> I'm not clear on what Debian needs here. There clearer you can be, the
> more likely we are to pick a solution that works for Debian as well as
> Tomcat.

I see two options:
1) Turn Tomcat Native into a "standard" dependency (bundled in its own
jar downloaded from Maven Central)
2) Add an independent Ant target that downloads the Tomcat Native source
files into the Tomcat source tree, the commit hash or tag being
specified in a build property.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Mark Thomas]

On 20/02/18 07:42, Emmanuel Bourg wrote:
> Le 14/02/2018 à 13:11, Rainer Jung a écrit :
> 
>> I guess we would bundle the Java sources in any source distribution we
>> provide. So only people wanting to do a release would need to run that
>> "grab Java files from Tomcat" step. The step would be done by the
>> release script.
> 
> Copying the source files at release time will not be enough since they
> are required to build the project even outside any release activity.

But they'd be in the source bundle. Isn't that sufficient to build off-line?

I'm not clear on what Debian needs here. There clearer you can be, the
more likely we are to pick a solution that works for Debian as well as
Tomcat.

> Also, someone checking out a previous tag will have to fetch the version
> of tcnative that was used at this time instead of the current HEAD of
> the repository. So this means the right hash/tag expected will have to
> be specified in the build properties.

Yep. This is essentially was is achieved with the external at the moment.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Emmanuel,

On 2/14/18 6:15 AM, Emmanuel Bourg wrote:
> Le 12/02/2018 à 19:43, Christopher Schultz a écrit :
> 
>> Is there also option 3) amend the build process to fetch the
>> source from svn?
> 
> This would be a bit inconvenient for Linux distributions like
> Debian that build Tomcat in offline mode.

I was not so clear. I was thinking "build process to assemble the
source distribution", not necessarily the "compile from source" build
process.

I hope that clears things up, and I think offline builds will still
work as expected. If someone wants to build from a fresh git-checkout,
well then, you have network access and can also fetch the tcnative
Java sources as well.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqHYLUdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhxwRAAos5NFrs64KuRg1p4
b/agJfZrkoCODlMNlpFq81WWf1YkDEMpZFw+P2kvZC6d6mb6fk/sCfqXEYNADlMm
PRLyvl6VCmmPalLPdULFUcDv3zDdVN2BHkxmZ6sl0Jmmj7YItpY0ZW7nhahmq7m7
MfgTpHA1jvoSsHX9WsKr+wxiiT5En9R1trt1zEFxa0U98S39XjXuncKcocSiUkGs
EoFJSUdagj9cOJ9YyH0YPySkx5DpgRTnQKYE8oJjPfjKA8dveQQaoHJPaf8rsJVq
TNHmouhW/UfvSI7D0Sw1liJ6V9EUmbEsM/kLvs5DZ27IAb4Cdga/AfrtHuIAyAL+
Xf/jjTP42wINyaOscdIpTHsp/CyzXyJnC1DI27w8R6fMXBt63nhUlgSNO0lrKmiE
cdAfH389341SwbIB/Y73RMa1T5vWA72qBvFi3xqBUMaVWsbIxhryks/XyPKU8fjf
wIkd4x6JFzmeNN13B1v/AK1nNmuNXRToO4XqUpOfBqLESW+jO4ev3DlI76zmNBq9
AVXlQMA7oxEyj0heX1TKIpclEPAx7S6PcVRZHY41zDBzEOHMHY+dN1003ExZo24w
AlifeqV8ptWbJr9My057Pg75nBvNm8pRTj6yPrDxPDAGNYJ9suVhlt35uus7oKIn
vIJY4NK2Y6+E7gNKhvc15ScoABA=
=i1Wf
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git repo for training content

[Mark Thomas]

On 15/02/18 16:09, Rémy Maucherat wrote:
> On Thu, Feb 15, 2018 at 4:57 PM, Mark Thomas  wrote:
> 
>> Hi,
>>
>> Now the date and venue are fixed for the training course (I need to
>> publish them) we need somewhere to put the training material.
>>
>> After some research my plan is to use reveal.js and GitHub pages. This
>> means we'll need a GitHib repo. I therefore plan to request an ASF GitHub
>> repo - "tomcat-training" to host this content. I'll probably do this
>> tomorrow unless there are any concerns or objections.
>>
> 
> +1

As you will have seen, I've created the repo and started to populate it.
I am VERY impressed with reveal.js so far.

My plan over the coming weeks includes:
- tweaking the default template to add some Tomcat branding
- fill out the content
- once we have some reasonable content publish it via github pages
- link to the training material from the website
- promote it on the users list along with a call for contributions

Obviously, there is a hard deadline 10 April to complete the first
course as that is when I have booked the venue for.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Git repo for training content

[Rémy Maucherat]

On Thu, Feb 15, 2018 at 4:57 PM, Mark Thomas  wrote:

> Hi,
>
> Now the date and venue are fixed for the training course (I need to
> publish them) we need somewhere to put the training material.
>
> After some research my plan is to use reveal.js and GitHub pages. This
> means we'll need a GitHib repo. I therefore plan to request an ASF GitHub
> repo - "tomcat-training" to host this content. I'll probably do this
> tomorrow unless there are any concerns or objections.
>

+1

Rémy

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Emmanuel Bourg]

Le 11/02/2018 à 21:36, Mark Thomas a écrit :

> Thoughts? comments?

I'd like to suggest an alternative: what about packaging the Java part
of tomcat-native into a jar (and potentially publishing it to Maven
Central) and then adding it to the Tomcat dependencies?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Rainer Jung]

Am 14.02.2018 um 12:15 schrieb Emmanuel Bourg:

Le 12/02/2018 à 19:43, Christopher Schultz a écrit :


Is there also option 3) amend the build process to fetch the source
from svn?


This would be a bit inconvenient for Linux distributions like Debian
that build Tomcat in offline mode.


I guess we would bundle the Java sources in any source distribution we 
provide. So only people wanting to do a release would need to run that 
"grab Java files from Tomcat" step. The step would be done by the 
release script.


Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Emmanuel Bourg]

Le 12/02/2018 à 19:43, Christopher Schultz a écrit :

> Is there also option 3) amend the build process to fetch the source
> from svn?

This would be a bit inconvenient for Linux distributions like Debian
that build Tomcat in offline mode.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Rainer Jung]

Am 13.02.2018 um 11:56 schrieb Mark Thomas:

On 12/02/18 18:43, Christopher Schultz wrote:

Mark,

On 2/11/18 3:36 PM, Mark Thomas wrote:

Currently, Tomcat Native uses an svn:external to pull in the
current Java source from trunk. With the switch to git, we'll need
a different solution.



Possible options:



1) Stop distributing Java elements of Tomcat Native in the Tomcat
Native release



2) Migrate Tomcat Native to git and use a sub-module



One point to note with option 2 is that, as far as I have been able
to determine so far, you can't add a sub-directory of another git
repo as a sub-module. It has to be the whole thing. That isn't
really what we want.



Thoughts? comments?


Is there also option 3) amend the build process to fetch the source
from svn?


It would be git but that is an implementation detail.


IIRC, there's no particular reason to have the Java elements from
tcnative actually *IN* the tcnative project. It's just a "build
detail", right?


That strikes me as a much better plan.

We will need to take care that build are repeatable. i.e. we need to
explicitly exactly which version of the code we want to pull in.
Currently we do this with the svn revision in the svn:external. We'll
need to use the SHA1 in git.


Or/and spend a tag which would not be used for a TC release but a 
tcnative Java parts release.


Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Mark Thomas]

On 12/02/18 18:43, Christopher Schultz wrote:
> Mark,
> 
> On 2/11/18 3:36 PM, Mark Thomas wrote:
>> Currently, Tomcat Native uses an svn:external to pull in the
>> current Java source from trunk. With the switch to git, we'll need
>> a different solution.
> 
>> Possible options:
> 
>> 1) Stop distributing Java elements of Tomcat Native in the Tomcat 
>> Native release
> 
>> 2) Migrate Tomcat Native to git and use a sub-module
> 
>> One point to note with option 2 is that, as far as I have been able
>> to determine so far, you can't add a sub-directory of another git
>> repo as a sub-module. It has to be the whole thing. That isn't
>> really what we want.
> 
>> Thoughts? comments?
> 
> Is there also option 3) amend the build process to fetch the source
> from svn?

It would be git but that is an implementation detail.

> IIRC, there's no particular reason to have the Java elements from
> tcnative actually *IN* the tcnative project. It's just a "build
> detail", right?

That strikes me as a much better plan.

We will need to take care that build are repeatable. i.e. we need to
explicitly exactly which version of the code we want to pull in.
Currently we do this with the svn revision in the svn:external. We'll
need to use the SHA1 in git.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/11/18 3:36 PM, Mark Thomas wrote:
> Currently, Tomcat Native uses an svn:external to pull in the
> current Java source from trunk. With the switch to git, we'll need
> a different solution.
> 
> Possible options:
> 
> 1) Stop distributing Java elements of Tomcat Native in the Tomcat 
> Native release
> 
> 2) Migrate Tomcat Native to git and use a sub-module
> 
> One point to note with option 2 is that, as far as I have been able
> to determine so far, you can't add a sub-directory of another git
> repo as a sub-module. It has to be the whole thing. That isn't
> really what we want.
> 
> Thoughts? comments?

Is there also option 3) amend the build process to fetch the source
from svn?

IIRC, there's no particular reason to have the Java elements from
tcnative actually *IN* the tcnative project. It's just a "build
detail", right?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqB4EkdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhD2hAAxvc1FCkfNCMO88Y3
ap5lyV3wME21cB/ZLWl+unLKDGgsdOqVf92Q8XkcC1mZ/u9TaR4TIaTJepR5zXBF
yJ4TXvLOq4iliW+5YA8WYDBZifZDgBd3Jb8bS1QPwYNN4RmDPbM1osaE4ZHv/KYX
HJzKEtDMF/ZXi3Dr7bZwlWAm3kht+PkbOFHbtuZtnuK96sXcX3ETiAk1H5LmZzoF
Dczf9cT2NIA0DJPHBDStCsUX/D3pgRjYw+ys7x7bywl4mmzSc6avkV+ph4v7Kfwv
gbwVJHaXomiv1wwEtGmW2vIXrP0oKWkUpQFm7vpFntUFNwHinOYL7CXnhhWxt3gy
OYvnsDFPP/buctgfy+RkSN2kRTiHVBc8UAJqajqiia9tqQDCRpLciEm8Mko+YKhA
YY+Mr1p8AdmULksE2LB0yf0xI+Y7FODBy5g7XDqeBTEHg9CzIinjgQceEoFDns2v
oU0FqLnhOB8dySp7aK4Y4Xw9mtUQVfzSK57isRw7Q0aQ4GuleoYKzEM9BUdfw5zz
64mvQwsoF23bF/5lXYIL0n5+p5YMF7lL1Won/YqxNrznVH47qFoNzgsrp5BWlk/9
DIIxdtx1oNXe5gfG28eawsaQGCi55/xt0OLKhBeZVhvEHJRI/aeDWAYzuqAaj7LQ
r1OgJsY8LuM0sX6VDfNNaDhjkHQ=
=8rf9
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] How to handle svn:external used by Tomcat Native

[Rainer Jung]

Am 11.02.2018 um 21:36 schrieb Mark Thomas:

Currently, Tomcat Native uses an svn:external to pull in the current
Java source from trunk. With the switch to git, we'll need a different
solution.

Possible options:

1) Stop distributing Java elements of Tomcat Native in the Tomcat
Native release

2) Migrate Tomcat Native to git and use a sub-module

One point to note with option 2 is that, as far as I have been able to
determine so far, you can't add a sub-directory of another git repo as a
sub-module. It has to be the whole thing. That isn't really what we want.

Thoughts? comments?


I think 1) would be OK. We could still bundle the classes for testing 
purposes during the release process. Migrating to tcnative could be a 
logical next step though.


Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] CI systems

[Mark Thomas]

On 05/02/18 10:23, Mark Thomas wrote:
> We'll need to update the CI systems (Gump, BuildBot) to work off git
> rather than svn. Both support this so this should be fairly simple.
> 
> My proposed plan is that we leave the CI systems pointing at svn to
> start with, migrate to a single git repo as discussed previously (steps
> on the wiki page) and, once we are happy with that repo, then switch
> over the CI systems.
> 
> Thoughts? Comments?

No feedback so the above approach is the plan I'll update the wiki with.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Git migration] Merge strategy

[Mark Thomas]

Thanks for all the input. Consensus appears to be for cherry-picking so
I'll update the wiki page accordingly and move onto the next question.

Mark


On 22/01/18 21:16, Mark Thomas wrote:
> The plan when we migrate to git is to migrate to single git repo with
> the following branches:
> 
> master - 9.0.x development
> tc8.5  - 8.5.x development
> tc8.0  - 8.0.x development
> tc7.0  - 7.0.x development
> 
> We need to decide how we are going to handle a fix that applies to
> multiple versions.
> 
> I can see two options:
> 
> 1. Make the change in master and cherry-pick as required to earlier
>versions. This is, essentially, what we do now in svn.
> 
> 2. Make the change in the earliest applicable version and them merge
>forward. This appears to be the more natural git way of doing things.
> 
> These options are based on my fairly limited understanding of git.
> Suggestions for other approaches welcome.
> 
> Thoughts? Comments?
> 
> Mark
> 
> -
> 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: [Git migration] Merge strategy

[Rainer Jung]

Am 23.01.2018 um 08:48 schrieb Rémy Maucherat:

On Mon, Jan 22, 2018 at 10:16 PM, Mark Thomas  wrote:


The plan when we migrate to git is to migrate to single git repo with
the following branches:

master - 9.0.x development
tc8.5  - 8.5.x development
tc8.0  - 8.0.x development
tc7.0  - 7.0.x development

We need to decide how we are going to handle a fix that applies to
multiple versions.

I can see two options:

1. Make the change in master and cherry-pick as required to earlier
versions. This is, essentially, what we do now in svn.

2. Make the change in the earliest applicable version and them merge
forward. This appears to be the more natural git way of doing things.



I've not seen 2 being done yet, to be honest.


I think the PHP project works that way.


These options are based on my fairly limited understanding of git.
Suggestions for other approaches welcome.

Thoughts? Comments?


I prefer option 1 as well, but can't judge on git-related pros and cons.

Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org