You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2019/02/20 21:33:10 UTC
Migrate SVN -> Git
Hi,
What do you think of migrating to Git as a primary VCS?
I've seen recent migration of Apache Calcite to Apache Gitbox (
https://gitbox.apache.org/ ), and it is kind of great.
The site can be hosted via gitbox as well (one typically creates a separate
git repository for the site like https://github.com/apache/calcite-site ).
It enables write access for GitHub repositories (e.g. committers can edit
PRs, edit issues, close, label them, etc).
Can you please express your opinion on that?
If you struggle what to say, you might find the below options useful:
[ ] ++1: 'Wow! I like this! Let's do it!'
[ ] +1: 'Let's do it!'
[ ] +0.9: 'This is a cool idea and i like it'
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20.02.19 um 22:33 schrieb Vladimir Sitnikov:
> Hi,
>
> What do you think of migrating to Git as a primary VCS?
> I've seen recent migration of Apache Calcite to Apache Gitbox (
> https://gitbox.apache.org/ ), and it is kind of great.
> The site can be hosted via gitbox as well (one typically creates a separate
> git repository for the site like https://github.com/apache/calcite-site ).
>
> It enables write access for GitHub repositories (e.g. committers can edit
> PRs, edit issues, close, label them, etc).
>
> Can you please express your opinion on that?
> If you struggle what to say, you might find the below options useful:
>
> [ ] ++1: 'Wow! I like this! Let's do it!'
> [x] +1: 'Let's do it!'
> [ ] +0.9: 'This is a cool idea and i like it'
Most of the time I work in a clone of the git repo clone of our svn, so
I think it will ease work for me.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
+1 too
Le mer. 20 févr. 2019 à 23:13, Philippe Mouawad <ph...@gmail.com>
a écrit :
> +1 for me but I wouldn't be the implementer
> Few questions:
>
> - What's the level of complexity ?
> - Is it done by Infrastructure ?
> - Are there any risks ?
>
>
> Thanks
>
>
> On Wed, Feb 20, 2019 at 10:33 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > Hi,
> >
> > What do you think of migrating to Git as a primary VCS?
> > I've seen recent migration of Apache Calcite to Apache Gitbox (
> > https://gitbox.apache.org/ ), and it is kind of great.
> > The site can be hosted via gitbox as well (one typically creates a
> separate
> > git repository for the site like https://github.com/apache/calcite-site
> ).
> >
> > It enables write access for GitHub repositories (e.g. committers can edit
> > PRs, edit issues, close, label them, etc).
> >
> > Can you please express your opinion on that?
> > If you struggle what to say, you might find the below options useful:
> >
> > [ ] ++1: 'Wow! I like this! Let's do it!'
> > [ ] +1: 'Let's do it!'
> > [ ] +0.9: 'This is a cool idea and i like it'
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir> re move to Gradle
This should be "re move to Git". Sorry for confusion.
In other words,
The results (re move to Git) so far are:
+1 (binding) Philippe Mouawad
++1 (binding) Vladimir Sitnikov
+1 (binding) Antonio Gomes Rodrigues
+1 Andrey Pokhilko
+1 Graham Russell
+1 (binding) Milamber
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 16.06.19 um 20:10 schrieb Vladimir Sitnikov:
> Philippe>Fixed and tested first PR merging
>
> Ok. Great.
>
> Should we use "squash and merge" / "rebase and merge" for PRs by default?
>
> You just created a merge commit "Merge pull request #468 from
> ubikloadpack/master", and merge commits might become complicated,
> especially when you merge commits that were created long ago.
> I don't think we want this for JMeter history:
> https://twitter.com/dominikhonnef/status/1126850717690552320
>
> I suggest we try to stick with linear history.
> What if we disable "merge" button and leave just "squash and merge" /
> "rebase and merge"?
As it is only a few people that can do a merge, I would try to first
teach those to use the alternatives before taking one away.
I tend to favor rebase and merge, as it keeps the smaller steps that
lead to the PR while giving a nice linear history after the merge.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>Fixed and tested first PR merging
Ok. Great.
Should we use "squash and merge" / "rebase and merge" for PRs by default?
You just created a merge commit "Merge pull request #468 from
ubikloadpack/master", and merge commits might become complicated,
especially when you merge commits that were created long ago.
I don't think we want this for JMeter history:
https://twitter.com/dominikhonnef/status/1126850717690552320
I suggest we try to stick with linear history.
What if we disable "merge" button and leave just "squash and merge" /
"rebase and merge"?
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Thanks Vladimir.
Fixed and tested first PR merging.
That's nice !
On Sun, Jun 16, 2019 at 7:11 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Philippe>Our build is marked as failed on github due to a commit on
> failing PR.
>
> I guess the reason is README.md explicitly refers branch=trunk, so we need
> to update README.md to point to "master" branch as well.
>
> As you can see, "master" build is ok:
> https://travis-ci.org/apache/jmeter/branches
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>Our build is marked as failed on github due to a commit on failing PR.
I guess the reason is README.md explicitly refers branch=trunk, so we need
to update README.md to point to "master" branch as well.
As you can see, "master" build is ok:
https://travis-ci.org/apache/jmeter/branches
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <pm...@apache.org>.
One thing I noticed since migration.
Our build is marked as failed on github due to a commit on failing PR.
i don’t think it was the case before.
Regards
On Thursday, June 13, 2019, Vladimir Sitnikov <si...@gmail.com>
wrote:
> Vladimir> https://github.com/apache/jmeter
> Philippe>Isn't it
>
> Just in case: https://github.com/apache/jmeter (with master=778016e..) is
> a
> **result** of cleanup v2.2.0
> The cleanup script is
> https://github.com/vlsi/jmeter-git-cleanup/tree/v2.2.0/clean_fork (you
> just use it as is, and you do not un-comment lines unless you are
> absolutely sure)
>
> PS. Are there Windows users? We might need Windows-based *.bat script,
> however as nobody asks for that I just ignore it.
>
> >Yes , I had used 2.1.1
> >Shall I run 2.2.0 on my current fork ?
>
> Do you have a backup?
> If you do, I would recommend get that and run 2.2.0 on top of it.
>
> Alternative option is to run 2.2.0 on top of "after cleanup v2.1.1" repo.
> Theoretically it should produce the same result (the only difference is
> CRLF issues, so cleanup 2.2.0 should work after 2.1.1 just fine).
> However I would be on a safe side and just ran v2.2.0 on top of your fork.
> At the end of the day, I have not tested all the possible cleanup execution
> orders.
>
> Note: I executed v2.2.0 in my own fork and it was just fine (I develop
> Gradle migration in that fork, and there are lots of historical branches as
> well).
> I did not have to clone-reclone that from github. I just copied repo in a
> side folder, copied cleanup scripts there and that was it.
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir> https://github.com/apache/jmeter
Philippe>Isn't it
Just in case: https://github.com/apache/jmeter (with master=778016e..) is a
**result** of cleanup v2.2.0
The cleanup script is
https://github.com/vlsi/jmeter-git-cleanup/tree/v2.2.0/clean_fork (you
just use it as is, and you do not un-comment lines unless you are
absolutely sure)
PS. Are there Windows users? We might need Windows-based *.bat script,
however as nobody asks for that I just ignore it.
>Yes , I had used 2.1.1
>Shall I run 2.2.0 on my current fork ?
Do you have a backup?
If you do, I would recommend get that and run 2.2.0 on top of it.
Alternative option is to run 2.2.0 on top of "after cleanup v2.1.1" repo.
Theoretically it should produce the same result (the only difference is
CRLF issues, so cleanup 2.2.0 should work after 2.1.1 just fine).
However I would be on a safe side and just ran v2.2.0 on top of your fork.
At the end of the day, I have not tested all the possible cleanup execution
orders.
Note: I executed v2.2.0 in my own fork and it was just fine (I develop
Gradle migration in that fork, and there are lots of historical branches as
well).
I did not have to clone-reclone that from github. I just copied repo in a
side folder, copied cleanup scripts there and that was it.
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Vladimir,
On Thu, Jun 13, 2019 at 5:37 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Just in case, I've pushed EOL v2.2.0 cleanup to
> https://github.com/apache/jmeter
Isn't it:
https://github.com/vlsi/jmeter-git-cleanup/tree/v2.2.0/clean_fork
>
>
> Travis is still in progress (
> https://travis-ci.org/apache/jmeter/builds/545287212 ), however I think it
> would be ok because final repository state is the same modulo line endings.
>
> @Philippe, did you succeed with fork cleanup?
>
Yes , I had used 2.1.1
https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork and
resubmitted a PR.
But then some other manipulations were done by Infra and now repo is unsync.
Shall I run 2.2.0 on my current fork ?
Or should I drop fork's master and run 2.2.0 ?
Thanks
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Just in case, I've pushed EOL v2.2.0 cleanup to
https://github.com/apache/jmeter
Travis is still in progress (
https://travis-ci.org/apache/jmeter/builds/545287212 ), however I think it
would be ok because final repository state is the same modulo line endings.
@Philippe, did you succeed with fork cleanup?
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Here you go:
https://github.com/vlsi/jmeter-git-cleanup/tree/v2.2.0/clean_fork (new
cleanup script + new bfg)
I have normalized line endings, and it looks like an improvement to me.
It is nice how "fix eol" commits become a no-op, thus "history browsing"
would be much simpler:
https://github.com/vlsi/jmeter-git-cleanup-result/commit/8f1496b2ec2c5f258d2b5216579e2a57fe96d950
The updated preview is https://github.com/vlsi/jmeter-git-cleanup-result
I've asked Chris to disable mail notifications and unlock master so I can
push updated repo to apache/jmeter.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe> had applied the cleanup procedure on a fork and pushed a PR.
Was that the first cleanup on that fork?
Did you use v2.1.1 script for cleanup?
Note: you can't run cleanup v.2.1.1 in case you used other cleaup scripts
before.
Did you copy blobExecCache directory from cleanup script?
Did you use bfg-1.13.2-vlsi-master-44b5b85.jar?
I tried to migrate a non-bare repository, and I identified that we still
have certain text files stored as CRLF in Git.
I thought we fixed those, however it looks like we still have issues.
It looks like a severe inconvenience (especially for checking out previous
releases).
What do you think if we step back a bit and run one more pass over
historical commits and normalize CRLF vs LF all over the place?
I think I can implement that (I'm going to reuse Ant's implementation), and
hopefully it won't take ages/gigabytes of RAM to process the sources.
Steps to reproduce (macOS):
git clone https://github.com/apache/jmeter jmeter_fromgithub
cd jmeter_fromgithub
git diff # no differences
Open bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js. This file
happens to be in CRLF format
rm bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
git reset --hard
git diff # shows sb-admin-2.js as modified
Alternative steps:
git clone https://github.com/apache/jmeter jmeter_fromgithub
cd jmeter_fromgithub
git diff # no differences
copy jmeter_fromgithub to jmeter_fromgithub2 (e.g. create a new folder and
copy all the files)
git diff # 26 differences, all related to bin/report-template/sbadmin2-1.0.7
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Thanks Vladimir for completing this migration.
I had applied the cleanup procedure on a fork and pushed a PR.
but there were some additional steps done for migration and fork is again
unsynched:
- Fork master branch is 16209 commits ahead, 16211 commits behind
apache:master.
What is the procedure to sync again?
Thanks
On Thursday, June 13, 2019, Vladimir Sitnikov <si...@gmail.com>
wrote:
> The repository is configured (mail notifications should go to commits@j.a.o
> ),
> and we can continue with JMeter development.
>
> The URLs are: https://github.com/apache/jmeter and
> https://gitbox.apache.org/repos/asf/jmeter.git
>
> Thanks everybody, and sorry for the disruption. Please let me know if you
> think something is not working right (e.g. git produces warnings or
> displays 'all files as modified' or whatever)
>
> Note: if you want push via GitHub and/or manage PRs, then you need to link
> your accounts via https://gitbox.apache.org/
>
> Note: theoretically GitHub allows for transparent use of SVN, however I
> have never tried it.
>
> Note: if you want to use your fork repository that you created before the
> cleanup, you should process it as per
> https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
>
>
> I guess we might want to update the site.
> So we need to figure out which git repo to use for the site (suddenly we
> have two: https://github.com/apache/jmeter-site and
> https://github.com/apache/jmeter-website), then we populate it and ask
> infra to setup site publish from that.
>
> Vladimir
>
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Hm, it looks like the set of files is smaller: 1.5M
At this point I'm +0 re removal of rhino jars as 1.5M could probably be
just ignored.
On the other hand, file removal can be implemented on top of previous
cleanup, so there's no need to re-clone, and so on.
Any thoughts?
43080ba9bab1 3832 lib/junit/test.jar
423c8a3297d8 4337 extras/ant-jmeter.jar
06a49dca69d1 5462 extras/ant-jmeter.jar
87c3d42360a8 6909 bin/Apache-JMeter.jar
df9d33b6a793 8088 extras/ant-jmeter.jar
8905dc13b989 8238 lib/excalibur-i18n-1.1.jar
115edd0b00c6 8782 extras/ant-jmeter.jar
6b648bb77ee2 9395 bin/Apache-JMeter.jar
bd7d15ab3275 11421 extras/ant-jmeter-1.1.1.jar
780b574cb24f 24538 lib/xpp3_min-1.1.3.4.I.jar
640441dad25a 24677 lib/xpp3_min-1.1.3.4.O.jar
813a9a830bd0 24956 lib/xpp3_min-1.1.4c.jar
a34d599e7bae 596528 lib/js.jar
2b926505d024 708951 lib/js_rhino1_6R5.jar
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
It looks like blob removal became a no-no in Apache infra somehow (see
https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16865674&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16865674
)
So:
1) We have to live with the current state of Git repo (which is not bad
though).
2) We should **refrain from adding huge blobs** to Git repo (e.g.
uncompressed pngs, jars, pdfs, etc, etc), as they increase repository size
very fast, and the blobs are hard to remove (== we need either approval
from vp-infra@a.o or something like that).
Of course, there are ways to cleanup (e.g. Git -> Git migration, so we keep
old Git repo intact, and ask a brand new repo), however it is kind of
complicated (however I would really like to watch the reaction of the infra
team on Git->Git migration :) ).
Note: it is not something new with Git. In SVN we would still like to avoid
adding (big) binary blobs to the repository.
The "new" problem now is it becomes more complicated to rip those blobs out
of the repository.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 16.06.19 um 20:27 schrieb Vladimir Sitnikov:
> Felix>As it is only a few people that can do a merge, I would try to first
>
> What I mean is GitHub's merge button.
Yes, I thought so. If there is a way to pre-select "Rebase and merge",
than do so :)
>
> Felix>Thanks for your work on this whole migration.
>
> Thanks.
> However, I see there 9MiB of jars left in the repo:
> b10a48fa41c3 14549 lib/jodd-log-3.6.4.jar
> 780b574cb24f 24538 lib/xpp3_min-1.1.3.4.I.jar
> 640441dad25a 24677 lib/xpp3_min-1.1.3.4.O.jar
> 813a9a830bd0 24956 lib/xpp3_min-1.1.4c.jar
> c73cf12b60e2 111892 lib/commons-pool2-2.4.1.jar
> 00bad5fda166 204806 lib/jodd-lagarto-3.6.4.jar
> 1d7417c40313 284184 lib/commons-codec-1.10.jar
> 111fef9c3634 307637 lib/dnsjava-2.1.7.jar
> 3a7fc266c3e3 314932 lib/junit-4.12.jar
> c006d90cbb14 379938 lib/jodd-core-3.6.4.jar
> a493c3b99d5f 538830 lib/xstream-1.4.8.jar
> 104e1660f2a7 560997 lib/tika-core-1.9.jar
> a34d599e7bae 596528 lib/js.jar
> 0defbe2138e1 679096 lib/tika-parsers-1.9.jar
> 2b926505d024 708951 lib/js_rhino1_6R5.jar
> a8b70c7e76c6 1037784 lib/rsyntaxtextarea-2.5.6.jar
> 76b6eaed61a1 1142627 lib/rhino-1.7R5.jar
> db99f8c288c7 2038489 lib/commons-math3-3.5.jar
>
> I've no idea how I missed that.
>
> Should we cleanup those as well?
If we don't loose the newly committed changes, I am OK with it.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>As it is only a few people that can do a merge, I would try to first
What I mean is GitHub's merge button.
Felix>Thanks for your work on this whole migration.
Thanks.
However, I see there 9MiB of jars left in the repo:
b10a48fa41c3 14549 lib/jodd-log-3.6.4.jar
780b574cb24f 24538 lib/xpp3_min-1.1.3.4.I.jar
640441dad25a 24677 lib/xpp3_min-1.1.3.4.O.jar
813a9a830bd0 24956 lib/xpp3_min-1.1.4c.jar
c73cf12b60e2 111892 lib/commons-pool2-2.4.1.jar
00bad5fda166 204806 lib/jodd-lagarto-3.6.4.jar
1d7417c40313 284184 lib/commons-codec-1.10.jar
111fef9c3634 307637 lib/dnsjava-2.1.7.jar
3a7fc266c3e3 314932 lib/junit-4.12.jar
c006d90cbb14 379938 lib/jodd-core-3.6.4.jar
a493c3b99d5f 538830 lib/xstream-1.4.8.jar
104e1660f2a7 560997 lib/tika-core-1.9.jar
a34d599e7bae 596528 lib/js.jar
0defbe2138e1 679096 lib/tika-parsers-1.9.jar
2b926505d024 708951 lib/js_rhino1_6R5.jar
a8b70c7e76c6 1037784 lib/rsyntaxtextarea-2.5.6.jar
76b6eaed61a1 1142627 lib/rhino-1.7R5.jar
db99f8c288c7 2038489 lib/commons-math3-3.5.jar
I've no idea how I missed that.
Should we cleanup those as well?
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
> Does it reproduce for the local repo only?
>yes
The solution is:
1) commit the changes (ensure `git status` "no modifications". untracked
files are fine)
2) remove the offending files (e.g. rm
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js)
3) git reset --hard (it will re-create the files with proper line endings)
Note: git reset --hard discards uncommitted modifications, so be careful if
you just copy-paste the commands one by one.
I think it happens because once upon a time Git learned that "those js
files have CRLF issues" and it just silenced the warning.
After you remove the files (just from the disk) and do reset --hard the
problem should go away.
Does it work for you?
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tue, Jun 18, 2019 at 10:47 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Does it reproduce when you clone the fork again?
>
No
> Does it reproduce for the local repo only?
>
yes
>
> In other words, does it happen when you do git clone
> https://github.com/ubikloadpack/jmeter.git (or whatever repo you use) ?
>
> No
> Vladimir
>
Thanks
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Does it reproduce when you clone the fork again?
Does it reproduce for the local repo only?
In other words, does it happen when you do git clone
https://github.com/ubikloadpack/jmeter.git (or whatever repo you use) ?
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
On a forked repository, I checkout a branch and run git status I have all
those files marked as to be commited due to CRLF/LF difference
On Tue, Jun 18, 2019 at 10:39 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >modified:
>
> >bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
>
> What's the step by step?
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
>modified:
>bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
What's the step by step?
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
I am having same issue as Felix with Line endings.
I am on Mac OSX , I applied:
- git config --global core.autocrlf input but issue persists.
But I always have those:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.colorhelpers.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.canvas.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.categories.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.crosshair.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.errorbars.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.fillbetween.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.image.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.navigate.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.resize.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.selection.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.stack.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.symbol.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.threshold.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.time.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.min.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.js
modified: bin/report-template/sbadmin2-1.0.7/dist/css/sb-admin-2.css
modified: bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
Regards
On Sun, Jun 16, 2019 at 8:22 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Thanks for your work on this whole migration.
>
> Pushing through gitbox worked like a charme.
>
> Felix
>
> Am 13.06.19 um 05:40 schrieb Vladimir Sitnikov:
> > The repository is configured (mail notifications should go to
> commits@j.a.o),
> > and we can continue with JMeter development.
> >
> > The URLs are: https://github.com/apache/jmeter and
> > https://gitbox.apache.org/repos/asf/jmeter.git
> >
> > Thanks everybody, and sorry for the disruption. Please let me know if you
> > think something is not working right (e.g. git produces warnings or
> > displays 'all files as modified' or whatever)
> >
> > Note: if you want push via GitHub and/or manage PRs, then you need to
> link
> > your accounts via https://gitbox.apache.org/
> >
> > Note: theoretically GitHub allows for transparent use of SVN, however I
> > have never tried it.
> >
> > Note: if you want to use your fork repository that you created before the
> > cleanup, you should process it as per
> > https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
> >
> >
> > I guess we might want to update the site.
> > So we need to figure out which git repo to use for the site (suddenly we
> > have two: https://github.com/apache/jmeter-site and
> > https://github.com/apache/jmeter-website), then we populate it and ask
> > infra to setup site publish from that.
> >
> > Vladimir
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Thanks for your work on this whole migration.
Pushing through gitbox worked like a charme.
Felix
Am 13.06.19 um 05:40 schrieb Vladimir Sitnikov:
> The repository is configured (mail notifications should go to commits@j.a.o),
> and we can continue with JMeter development.
>
> The URLs are: https://github.com/apache/jmeter and
> https://gitbox.apache.org/repos/asf/jmeter.git
>
> Thanks everybody, and sorry for the disruption. Please let me know if you
> think something is not working right (e.g. git produces warnings or
> displays 'all files as modified' or whatever)
>
> Note: if you want push via GitHub and/or manage PRs, then you need to link
> your accounts via https://gitbox.apache.org/
>
> Note: theoretically GitHub allows for transparent use of SVN, however I
> have never tried it.
>
> Note: if you want to use your fork repository that you created before the
> cleanup, you should process it as per
> https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
>
>
> I guess we might want to update the site.
> So we need to figure out which git repo to use for the site (suddenly we
> have two: https://github.com/apache/jmeter-site and
> https://github.com/apache/jmeter-website), then we populate it and ask
> infra to setup site publish from that.
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
The repository is configured (mail notifications should go to commits@j.a.o),
and we can continue with JMeter development.
The URLs are: https://github.com/apache/jmeter and
https://gitbox.apache.org/repos/asf/jmeter.git
Thanks everybody, and sorry for the disruption. Please let me know if you
think something is not working right (e.g. git produces warnings or
displays 'all files as modified' or whatever)
Note: if you want push via GitHub and/or manage PRs, then you need to link
your accounts via https://gitbox.apache.org/
Note: theoretically GitHub allows for transparent use of SVN, however I
have never tried it.
Note: if you want to use your fork repository that you created before the
cleanup, you should process it as per
https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
I guess we might want to update the site.
So we need to figure out which git repo to use for the site (suddenly we
have two: https://github.com/apache/jmeter-site and
https://github.com/apache/jmeter-website), then we populate it and ask
infra to setup site publish from that.
Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>When can we complete migration ?
I guess we can if everybody is OK with the contents.
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Vladimir ,
What’s the next step?
When can we complete migration ?
Thanks
On Monday, June 10, 2019, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
>
> Am 10.06.19 um 14:06 schrieb Vladimir Sitnikov:
> > Felix>They will have to be rebased to the new repo and reopened anyway,
> or
> > do
> > Felix>you mean old closed PRs?
> >
> > I just assume we can never rebase all the forks in the wild :)
> > On the other hand, if we need "old git" once again, we can re-create it
> > from SVN.
> > So there's no need to keep "backup git" and/or insert urls.
>
> No, we can't rebase those repositories, but hopefully the owners of
> those repositories can rebase their work onto origin/head and then do
> git format-patch/git am to the new forks.
>
> >
> > Felix>Do you think that is a problem?
> >
> > No.
>
> For me it is not a problem either, as any change in the repo would have
> led to this.
>
> Felix
>
> >
> > Vladimir
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 10.06.19 um 14:06 schrieb Vladimir Sitnikov:
> Felix>They will have to be rebased to the new repo and reopened anyway, or
> do
> Felix>you mean old closed PRs?
>
> I just assume we can never rebase all the forks in the wild :)
> On the other hand, if we need "old git" once again, we can re-create it
> from SVN.
> So there's no need to keep "backup git" and/or insert urls.
No, we can't rebase those repositories, but hopefully the owners of
those repositories can rebase their work onto origin/head and then do
git format-patch/git am to the new forks.
>
> Felix>Do you think that is a problem?
>
> No.
For me it is not a problem either, as any change in the repo would have
led to this.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>They will have to be rebased to the new repo and reopened anyway, or
do
Felix>you mean old closed PRs?
I just assume we can never rebase all the forks in the wild :)
On the other hand, if we need "old git" once again, we can re-create it
from SVN.
So there's no need to keep "backup git" and/or insert urls.
Felix>Do you think that is a problem?
No.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 10.06.19 um 11:57 schrieb Vladimir Sitnikov:
> Felix>So compared to removal we pay 13 MiB for keeping old images?
>
> Something like that.
I can live with that.
>
> Felix>Were are those references used (I suspect in old PRs and bugzilla
> Felix>entries)?
>
> Old PRs, forks.
> I don't think Git ids were used in Bugzilla.
They will have to be rebased to the new repo and reopened anyway, or do
you mean old closed PRs?
Do you think that is a problem?
>
> Felix>If I set core.autocrlf to input
>
> In fact, it is the recommended way to go by default:
> https://help.github.com/en/articles/dealing-with-line-endings
>
> My macOS is configured with core.autocrlf=input and Windows is configured
> with core.autocrlf=true.
>
> However, the very same article says that .gitattributes file overrides
> "defaults", that is why adding .gitattributes to back branches should
> theoretically help even for "misconfigured" defaults.
> Adding .gitignore to all commits is not trivial though.
I think it is enough to add a little note to the developer docs. It
works on my machine ;)
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>So compared to removal we pay 13 MiB for keeping old images?
Something like that.
Felix>Were are those references used (I suspect in old PRs and bugzilla
Felix>entries)?
Old PRs, forks.
I don't think Git ids were used in Bugzilla.
Felix>If I set core.autocrlf to input
In fact, it is the recommended way to go by default:
https://help.github.com/en/articles/dealing-with-line-endings
My macOS is configured with core.autocrlf=input and Windows is configured
with core.autocrlf=true.
However, the very same article says that .gitattributes file overrides
"defaults", that is why adding .gitattributes to back branches should
theoretically help even for "misconfigured" defaults.
Adding .gitignore to all commits is not trivial though.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 10.06.19 um 11:31 schrieb Felix Schumacher:
> Am 10.06.19 um 10:14 schrieb Vladimir Sitnikov:
>> Felix>My problem here is, that I sometimes checkout a historic version and
>> Felix>can't get away from it, as git complains that the files have changed
>>
>> Please provide the exact steps to reproduce.
>> So far git checkout v213 V2_13; git checkout master; works for me just fine
>> when using Windows/macOS
> Under ubuntu 18.04 I used the following steps:
>
> $ mkdir test
> $ cd test
> $ git clone https://github.com/apache/jmeter
>
> Cloning into 'jmeter'...
> remote: Enumerating objects: 191859, done.
> remote: Total 191859 (delta 0), reused 0 (delta 0), pack-reused 191859
> Receiving objects: 100% (191859/191859), 88.72 MiB | 5.46 MiB/s, done.
> Resolving deltas: 100% (102811/102811), done.
>
> $ cd jmeter
> $ git checkout v2_13
>
> error: Your local changes to the following files would be overwritten by
> checkout:
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.colorhelpers.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.canvas.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.categories.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.crosshair.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.errorbars.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.fillbetween.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.image.js
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.navigate.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.resize.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.selection.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.stack.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.symbol.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.threshold.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.time.js
>
> bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.css
>
> bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.min.css
>
> bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.css
>
> bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.js
> bin/report-template/sbadmin2-1.0.7/dist/css/sb-admin-2.css
> bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
> Please commit your changes or stash them before you switch branches.
> Aborting
>
> $ git status
>
> On branch master
> Your branch is up to date with 'origin/master'.
>
> Changes not staged for commit:
> (use "git add <file>..." to update what will be committed)
> (use "git checkout -- <file>..." to discard changes in working directory)
>
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.colorhelpers.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.canvas.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.categories.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.crosshair.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.errorbars.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.fillbetween.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.image.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.navigate.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.resize.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.selection.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.stack.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.symbol.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.threshold.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.time.js
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.css
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.min.css
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.css
> modified:
> bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.js
> modified: bin/report-template/sbadmin2-1.0.7/dist/css/sb-admin-2.css
> modified: bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ git diff
>
> $ git diff | head
> warning: CRLF will be replaced by LF in
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in
> bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in
> bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js.
> The file will have its original line endings in your working directory.
> ...
>
> $ git config -l
>
> push.default=simple
> alias.tree=log --graph --decorate --pretty=oneline --abbrev-commit
> core.repositoryformatversion=0
> core.filemode=true
> core.bare=false
> core.logallrefupdates=true
> remote.origin.url=https://github.com/apache/jmeter
> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
> branch.master.remote=origin
> branch.master.merge=refs/heads/master
>
> Tell me, if you need more info.
Looking a bit further into this. If I set core.autocrlf to input with
$ git config --global core.autocrlf=input
the checkout works. Did you have this config setting enabled?
Felix
>
>> Felix>Yes, for future versions of our source, that would be a nice
>> enhancement.
>>
>> I've kept all the css, js, etc files.
>> I've ran pngquant (2.12.2, January 2018, libpng 1.6.37) through all the
>> historical commits.
>>
>> It results in 53MiB repository (it was 40 when historical png were just
>> removed).
> Thanks for your work. I really think it is better to keep those old
> images (and if they are quant'ed, all the better).
>
> The 53 MiB is the amount of space they use, right? So compared to
> removal we pay 13 MiB for keeping old images?
>
>> Hopefully multi-megabyte files won't be pushed to the repository, and I
>> hope JS/CSS dependencies would be managed though Webpack (or whatever).
>> I guess "component UI" images can be generated automatically at build time,
>> however that's a side discussion.
> +1 to both. But I think the generation of component UI will be more
> complicated.
>> The updated repository: https://github.com/apache/jmeter
>> SVN references are good,
>> Git references are good.
>> Travis build passes ( https://travis-ci.org/apache/jmeter/builds/543612661 )
>>
>> Note: migrate procedure is updated. The key change is you need my release
>> of BFG.
>> See https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
>>
>>
>> PS In fact, references to "old" Git commit ids would be more or less
>> useless without "old Git repo".
>> I just thought we could create a "readonly" Git repo, and use links that
>> point to commits in that repository instead of just current "commit ids".
>> Any thoughts on that? It can be done quite easily (I use my own build of
>> BFG anyway, so I can add http://github.com/apache/jmeter-svn-mirror/...
>> there)
>> On the other hand, I'm +-0 about that since I think the new Git repo is
>> just fine, and just commit id is sufficient for the search purposes.
> Were are those references used (I suspect in old PRs and bugzilla
> entries)? Most of the referenced commits can be identified by their svn
> revision, which is embedded in the old commit messages, though.
>
> So I don't think this is a big problem.
>
>> Vladimir
>>
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 10.06.19 um 10:14 schrieb Vladimir Sitnikov:
> Felix>My problem here is, that I sometimes checkout a historic version and
> Felix>can't get away from it, as git complains that the files have changed
>
> Please provide the exact steps to reproduce.
> So far git checkout v213 V2_13; git checkout master; works for me just fine
> when using Windows/macOS
Under ubuntu 18.04 I used the following steps:
$ mkdir test
$ cd test
$ git clone https://github.com/apache/jmeter
Cloning into 'jmeter'...
remote: Enumerating objects: 191859, done.
remote: Total 191859 (delta 0), reused 0 (delta 0), pack-reused 191859
Receiving objects: 100% (191859/191859), 88.72 MiB | 5.46 MiB/s, done.
Resolving deltas: 100% (102811/102811), done.
$ cd jmeter
$ git checkout v2_13
error: Your local changes to the following files would be overwritten by
checkout:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.colorhelpers.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.canvas.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.categories.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.crosshair.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.errorbars.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.fillbetween.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.image.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.navigate.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.resize.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.selection.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.stack.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.symbol.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.threshold.js
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.time.js
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.css
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.min.css
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.css
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.js
bin/report-template/sbadmin2-1.0.7/dist/css/sb-admin-2.css
bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
Please commit your changes or stash them before you switch branches.
Aborting
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.colorhelpers.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.canvas.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.categories.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.crosshair.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.errorbars.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.fillbetween.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.image.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.navigate.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.resize.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.selection.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.stack.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.symbol.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.threshold.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/flot/jquery.flot.time.js
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/font-awesome/css/font-awesome.min.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.css
modified:
bin/report-template/sbadmin2-1.0.7/bower_components/metisMenu/dist/metisMenu.min.js
modified: bin/report-template/sbadmin2-1.0.7/dist/css/sb-admin-2.css
modified: bin/report-template/sbadmin2-1.0.7/dist/js/sb-admin-2.js
no changes added to commit (use "git add" and/or "git commit -a")
$ git diff
$ git diff | head
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.min.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.tooltip.source.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot/excanvas.js.
The file will have its original line endings in your working directory.
...
$ git config -l
push.default=simple
alias.tree=log --graph --decorate --pretty=oneline --abbrev-commit
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/apache/jmeter
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
Tell me, if you need more info.
>
> Felix>Yes, for future versions of our source, that would be a nice
> enhancement.
>
> I've kept all the css, js, etc files.
> I've ran pngquant (2.12.2, January 2018, libpng 1.6.37) through all the
> historical commits.
>
> It results in 53MiB repository (it was 40 when historical png were just
> removed).
Thanks for your work. I really think it is better to keep those old
images (and if they are quant'ed, all the better).
The 53 MiB is the amount of space they use, right? So compared to
removal we pay 13 MiB for keeping old images?
>
> Hopefully multi-megabyte files won't be pushed to the repository, and I
> hope JS/CSS dependencies would be managed though Webpack (or whatever).
> I guess "component UI" images can be generated automatically at build time,
> however that's a side discussion.
+1 to both. But I think the generation of component UI will be more
complicated.
>
> The updated repository: https://github.com/apache/jmeter
> SVN references are good,
> Git references are good.
> Travis build passes ( https://travis-ci.org/apache/jmeter/builds/543612661 )
>
> Note: migrate procedure is updated. The key change is you need my release
> of BFG.
> See https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
>
>
> PS In fact, references to "old" Git commit ids would be more or less
> useless without "old Git repo".
> I just thought we could create a "readonly" Git repo, and use links that
> point to commits in that repository instead of just current "commit ids".
> Any thoughts on that? It can be done quite easily (I use my own build of
> BFG anyway, so I can add http://github.com/apache/jmeter-svn-mirror/...
> there)
> On the other hand, I'm +-0 about that since I think the new Git repo is
> just fine, and just commit id is sufficient for the search purposes.
Were are those references used (I suspect in old PRs and bugzilla
entries)? Most of the referenced commits can be identified by their svn
revision, which is embedded in the old commit messages, though.
So I don't think this is a big problem.
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>My problem here is, that I sometimes checkout a historic version and
Felix>can't get away from it, as git complains that the files have changed
Please provide the exact steps to reproduce.
So far git checkout v213 V2_13; git checkout master; works for me just fine
when using Windows/macOS
Felix>Yes, for future versions of our source, that would be a nice
enhancement.
I've kept all the css, js, etc files.
I've ran pngquant (2.12.2, January 2018, libpng 1.6.37) through all the
historical commits.
It results in 53MiB repository (it was 40 when historical png were just
removed).
Hopefully multi-megabyte files won't be pushed to the repository, and I
hope JS/CSS dependencies would be managed though Webpack (or whatever).
I guess "component UI" images can be generated automatically at build time,
however that's a side discussion.
The updated repository: https://github.com/apache/jmeter
SVN references are good,
Git references are good.
Travis build passes ( https://travis-ci.org/apache/jmeter/builds/543612661 )
Note: migrate procedure is updated. The key change is you need my release
of BFG.
See https://github.com/vlsi/jmeter-git-cleanup/tree/v2.1.1/clean_fork
PS In fact, references to "old" Git commit ids would be more or less
useless without "old Git repo".
I just thought we could create a "readonly" Git repo, and use links that
point to commits in that repository instead of just current "commit ids".
Any thoughts on that? It can be done quite easily (I use my own build of
BFG anyway, so I can add http://github.com/apache/jmeter-svn-mirror/...
there)
On the other hand, I'm +-0 about that since I think the new Git repo is
just fine, and just commit id is sufficient for the search purposes.
Vladimir
>
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 09.06.19 um 11:35 schrieb Vladimir Sitnikov:
> Felix> It would be great, if those deletion could be reduced to the
> replacement
> Felix> of re-quant'ed pngs, but I fear that is just too much work
>
> Unfortunately, BFG does not support for png quantization, and I'm not that
> fond of implementing that
> taking into account the amount of comments in this thread.
> Going with git filter-branch is not an option because it is extremely slow
> at JMeter scale.
No I didn't mean, that the quantization should be done inside of bfg. I
wanted to point out, that there were two reasons for png replacement in
our history:
* Screenshots changed because functionality changed (those would be
great to keep in our history)
* quant'ing (those would be great to loose from our history)
>
> Felix >Would it be possible to exclude the xdocs path from css and svg
> removal?
>
> The exact list of removed ids is listed in
> https://github.com/vlsi/jmeter-git-cleanup/blob/v1.0.0/clean_fork/deleted-files.txt
> Feel free to provide suggestions.
That is the file I looked at and found the xdocs references.
Other files I think should be kept are:
asf-logo.*
logo.* (old logo is quite big, but of historical interest IMHO)
new-style.css
style.css
>
> Re "css", there are files like bootstrap.css (140K), bootstrap.css.map
> (3.8M) which I don't think are crucial.
Those are the ones from our report feature. I am not sure, how well old
versions of reporting work with "newer" versions of bootstrap.
> I think xdocs/css/new-style.css can be kept though.
Please :)
> It might be a nice idea to download JS dependencies from external
> repositories for both site and report.
Yes, for future versions of our source, that would be a nice enhancement.
>
> Felix>tag v2_13
> Felix>warning: CRLF will be replaced by LF in
>
> Probably you want to add .gitattributes file that would specify which files
> are text and which are binary.
> I think we could add ".gitattributes" file to the initial Git commit,
> however it would make cleanup procedure (for forks) more complicated.
> I guess there's no BFG option to add a file.
My problem here is, that I sometimes checkout a historic version and
can't get away from it, as git complains that the files have changed.
Adding .gitattributes on those versions won't help me.
Any other way to get my checkout working in such a case?
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix> It would be great, if those deletion could be reduced to the
replacement
Felix> of re-quant'ed pngs, but I fear that is just too much work
Unfortunately, BFG does not support for png quantization, and I'm not that
fond of implementing that
taking into account the amount of comments in this thread.
Going with git filter-branch is not an option because it is extremely slow
at JMeter scale.
Felix >Would it be possible to exclude the xdocs path from css and svg
removal?
The exact list of removed ids is listed in
https://github.com/vlsi/jmeter-git-cleanup/blob/v1.0.0/clean_fork/deleted-files.txt
Feel free to provide suggestions.
Re "css", there are files like bootstrap.css (140K), bootstrap.css.map
(3.8M) which I don't think are crucial.
I think xdocs/css/new-style.css can be kept though.
It might be a nice idea to download JS dependencies from external
repositories for both site and report.
Felix>tag v2_13
Felix>warning: CRLF will be replaced by LF in
Probably you want to add .gitattributes file that would specify which files
are text and which are binary.
I think we could add ".gitattributes" file to the initial Git commit,
however it would make cleanup procedure (for forks) more complicated.
I guess there's no BFG option to add a file.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Hi Vladimir,
I cloned the new jmeter repo on my linux system and wanted to checkout
tag v2_13 (irrelevant information :), but git would not let me do that
as it thought that I had modified some files under
bin/report-template/sbadmin2...
git diff shows something along the lines:
warning: CRLF will be replaced by LF in
bin/report-template/sbadmin2-1.0.7/bower_components/flot.tooltip/js/jquery.flot.js.
The file will have its original line endings in your working directory.
Is this expected?
Felix
Am 08.06.19 um 20:13 schrieb Vladimir Sitnikov:
> Hi,
>
> I'm glad we have progress here.
> Chris moved SVN to a read-only mode, and I've cleaned Git repo.
>
> Please review the cleanup result at https://github.com/apache/jmeter
> Unfortunately, gitbox repo
> ( https://gitbox.apache.org/repos/asf?p=jmeter.git ) misses tags for
> some reason, however I think it will be resolved soon (INFRA-18499).
>
> Please vote regarding the contents of jmeter.git:
>
> [ ] +1: I support use of jmeter.git
> [ ] -1: I do not support that because ...
>
> Here's my vote: ++1
>
> Note: there were 10 open PRs which were unexpectedly closed by the
> removal of "trunk" branch.
> In order to proceed with PRs the same cleanup should be performed in
> contributors' repositories.
> After migration to Apache GitBox, committers would be able to push to
> PR branches (to the relative branches of contributors repos), so PR
> update could be either done by a contributor or by a JMeter committer.
> I'm sure it does not block git repo review/svn->git migration.
>
> The modifications I did were:
> 1) Remove of docs/ folder
> 2) Remove docs- branches
> 3) Remove "test" tags
> 4) Remove RC tags (as suggested in "JMeter release creation" wiki)
> 5) Remove all historical versions of the following
> files: '*.{class,jar,png,gif,jtl,js,map,css,svg,odt,pdf,sxi}'.
> The main case there is "old, unoptimized pngs" which literally took 40MiB
>
> The exact list of removed blobs is attached (see deleted-files.zip)
> The log of updated/removed refs is attached (see git_push.log).
>
> PS. The above is the same procedure I did to produce
> jmeter-git-cleanup-result with extra removal of RC tags.
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 08.06.19 um 20:13 schrieb Vladimir Sitnikov:
> Hi,
>
> I'm glad we have progress here.
> Chris moved SVN to a read-only mode, and I've cleaned Git repo.
>
> Please review the cleanup result at https://github.com/apache/jmeter
> Unfortunately, gitbox repo
> ( https://gitbox.apache.org/repos/asf?p=jmeter.git ) misses tags for
> some reason, however I think it will be resolved soon (INFRA-18499).
>
> Please vote regarding the contents of jmeter.git:
>
> [ ] +1: I support use of jmeter.git
> [ ] -1: I do not support that because ...
>
> Here's my vote: ++1
>
> Note: there were 10 open PRs which were unexpectedly closed by the
> removal of "trunk" branch.
> In order to proceed with PRs the same cleanup should be performed in
> contributors' repositories.
> After migration to Apache GitBox, committers would be able to push to
> PR branches (to the relative branches of contributors repos), so PR
> update could be either done by a contributor or by a JMeter committer.
> I'm sure it does not block git repo review/svn->git migration.
>
> The modifications I did were:
> 1) Remove of docs/ folder
> 2) Remove docs- branches
> 3) Remove "test" tags
> 4) Remove RC tags (as suggested in "JMeter release creation" wiki)
> 5) Remove all historical versions of the following
> files: '*.{class,jar,png,gif,jtl,js,map,css,svg,odt,pdf,sxi}'.
I don't think that removing historical versions of css, svg and js (even
jtl and the document files odt, pdf and sxi) are a good idea. At least
css, svg and js could be relevant to produce the "correct" old web site
again, if needed.
Would it be possible to exclude the xdocs path from css and svg removal?
The logo png would probably be a good candidate for exclusion, too.
And I still know, that svn will not be gone.
> The main case there is "old, unoptimized pngs" which literally took 40MiB
It would be great, if those deletion could be reduced to the replacement
of re-quant'ed pngs, but I fear that is just too much work.
Felix
>
> The exact list of removed blobs is attached (see deleted-files.zip)
> The log of updated/removed refs is attached (see git_push.log).
>
> PS. The above is the same procedure I did to produce
> jmeter-git-cleanup-result with extra removal of RC tags.
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've identified a defect: "Former-commit-id" footers were referencing
invalid commit Git ids.
Relevant BFG issue is https://github.com/rtyley/bfg-repo-cleaner/issues/112 ,
and it turns out the order of BFG commands is important.
I've updated the scripts, and refreshed
https://github.com/vlsi/jmeter-git-cleanup-result
I'll update apache/jmeter repository as master branch is unprotected.
Philippe>what must cloned repositories do after this operation to updated
their PR ?
They can use the following script:
https://github.com/vlsi/jmeter-git-cleanup/tree/v1.0.0/clean_fork
You copy the script to a fork repo, download bfg-1.13.0.jar, launch the
script, then you remove bfg jar and cleanup scripts.
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
I made some random checks on:
- Old tags presence
- History of files
Didn't see problems , so I tend to [X] +1: I support use of jmeter.git
@Vladimir Sitnikov <si...@gmail.com> , what must cloned
repositories do after this operation to updated their PR ?
Thanks
On Sat, Jun 8, 2019 at 8:46 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Philippe>AFAIU, the switch has been done no?
>
> No
>
> Philippe>What is the vote about exactly ?
>
> Before we switch to Git, we need to agree that the current state of
> https://github.com/apache/jmeter looks good to proceed.
>
> We are at step 4 of
>
> https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16855765&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16855765
>
> Chris>4. Project signs off on new cleaned up repo state
>
> As we agree the git repo looks good, we can enable write access for
> committers and proceed with JMeter development.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>AFAIU, the switch has been done no?
No
Philippe>What is the vote about exactly ?
Before we switch to Git, we need to agree that the current state of
https://github.com/apache/jmeter looks good to proceed.
We are at step 4 of
https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16855765&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16855765
Chris>4. Project signs off on new cleaned up repo state
As we agree the git repo looks good, we can enable write access for
committers and proceed with JMeter development.
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Vladimir,
What is the vote about exactly ?
AFAIU, the switch has been done no?
Otherwise please clarify to me.
Thanks
Regards
On Saturday, June 8, 2019, Vladimir Sitnikov <si...@gmail.com>
wrote:
> Hi,
>
> I'm glad we have progress here.
> Chris moved SVN to a read-only mode, and I've cleaned Git repo.
>
> Please review the cleanup result at https://github.com/apache/jmeter
> Unfortunately, gitbox repo ( https://gitbox.apache.org/
> repos/asf?p=jmeter.git ) misses tags for some reason, however I think it
> will be resolved soon (INFRA-18499).
>
> Please vote regarding the contents of jmeter.git:
>
> [ ] +1: I support use of jmeter.git
> [ ] -1: I do not support that because ...
>
> Here's my vote: ++1
>
> Note: there were 10 open PRs which were unexpectedly closed by the removal
> of "trunk" branch.
> In order to proceed with PRs the same cleanup should be performed in
> contributors' repositories.
> After migration to Apache GitBox, committers would be able to push to PR
> branches (to the relative branches of contributors repos), so PR update
> could be either done by a contributor or by a JMeter committer.
> I'm sure it does not block git repo review/svn->git migration.
>
> The modifications I did were:
> 1) Remove of docs/ folder
> 2) Remove docs- branches
> 3) Remove "test" tags
> 4) Remove RC tags (as suggested in "JMeter release creation" wiki)
> 5) Remove all historical versions of the following
> files: '*.{class,jar,png,gif,jtl,js,map,css,svg,odt,pdf,sxi}'.
> The main case there is "old, unoptimized pngs" which literally took 40MiB
>
> The exact list of removed blobs is attached (see deleted-files.zip)
> The log of updated/removed refs is attached (see git_push.log).
>
> PS. The above is the same procedure I did to produce
> jmeter-git-cleanup-result with extra removal of RC tags.
>
> Vladimir
>
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Hi,
I'm glad we have progress here.
Chris moved SVN to a read-only mode, and I've cleaned Git repo.
Please review the cleanup result at https://github.com/apache/jmeter
Unfortunately, gitbox repo (
https://gitbox.apache.org/repos/asf?p=jmeter.git ) misses tags for some
reason, however I think it will be resolved soon (INFRA-18499).
Please vote regarding the contents of jmeter.git:
[ ] +1: I support use of jmeter.git
[ ] -1: I do not support that because ...
Here's my vote: ++1
Note: there were 10 open PRs which were unexpectedly closed by the removal
of "trunk" branch.
In order to proceed with PRs the same cleanup should be performed in
contributors' repositories.
After migration to Apache GitBox, committers would be able to push to PR
branches (to the relative branches of contributors repos), so PR update
could be either done by a contributor or by a JMeter committer.
I'm sure it does not block git repo review/svn->git migration.
The modifications I did were:
1) Remove of docs/ folder
2) Remove docs- branches
3) Remove "test" tags
4) Remove RC tags (as suggested in "JMeter release creation" wiki)
5) Remove all historical versions of the following
files: '*.{class,jar,png,gif,jtl,js,map,css,svg,odt,pdf,sxi}'.
The main case there is "old, unoptimized pngs" which literally took 40MiB
The exact list of removed blobs is attached (see deleted-files.zip)
The log of updated/removed refs is attached (see git_push.log).
PS. The above is the same procedure I did to produce
jmeter-git-cleanup-result with extra removal of RC tags.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
It is sad that there's no much feedback on "git repository contents"
besides "+1 re migration in general".
Sebb had concerns, however those have been successfully resolved.
Note: the cleanup procedure is reproducible (at least it produces the same
result every time for me).
In other words, even (in very unlikely case) if we miss a file or a tag
(e.g. if "test" branch turns out to be crucial), we would still be able to
re-add the file/branch/tag later.
So I would suggest to just move to Git and see how it plays in practice.
It would still be nice to hear opinions on
https://github.com/vlsi/jmeter-git-cleanup-result even in case you voted
regarding Git migration.
Otherwise I would assume there's an agreement to proceed and ask (~6th
June, 15:00UTC) Infra to move SVN into read-only mode.
Note: technically speaking, voting re vlsi/jmeter-git-cleanup-result
repository means nothing. In any case we would need to analyze and agree on
apache/jmeter repository after SVN becomes read-only. However my intention
is to make those two equal modulo "gradle" branch which won't appear in
apache/jmeter.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>The JIRA issue is not yet signed off by Infra.
Just in case, here's what Chris proposes (see
https://issues.apache.org/jira/browse/INFRA-18499 )
Chris>1. Project agrees on cleanup approach and approves sync state of the
current git repo
Chris>2. Infra makes svn read-only
Chris>3. Infra disables sync process and allows [~vladimirsitnikov] access
to perform the cleanup on github.com/apache/jmeter
Chris>4. Project signs off on new cleaned up repo state
Chris>5. Infra enables gitbox and sets up permissions properly
Chris>Please let me know the results of step 1 and a timeline of when you
want to start the process.
So the question boils down to "timeline of when we want to start the
process".
I suggest to start on the 5th or the 6th of June.
Just in case, the up-to-date result of cleanup is available at
https://github.com/vlsi/jmeter-git-cleanup-result
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>The JIRA issue is not yet signed off by Infra.
It is.
If you think something is missing, please clarify exactly.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Tue, 4 Jun 2019 at 06:37, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> but the other still applies, i.e. is
> sebb>Infra OK with dropping files during conversion?
>
> As per INFRA-18499:
>
> Chris>A documented note of the blob removal process (script) and
> Chris>a list of the removed objects should be sufficient if the project
> agrees that it is so.
This is an partial extract of the response, and omits several concerns
that Infra have about the proposed process.
> Hopefully it resolves both concerns.
The JIRA issue is not yet signed off by Infra.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> but the other still applies, i.e. is
sebb>Infra OK with dropping files during conversion?
As per INFRA-18499:
Chris>A documented note of the blob removal process (script) and
Chris>a list of the removed objects should be sufficient if the project
agrees that it is so.
Hopefully it resolves both concerns.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Git repo looks good to me, however there's $Id$ used in xml files like the
following:
<document prev="build-ftp-test-plan.html"
next="build-ldapext-test-plan.html" id="$Id$">
I think we should deal with that $id$ in Gradle-based build.
Other than that, Gradle build produces source/binary artifacts with exactly
the same SHA512 for original and cleaned Git repositories.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 28. Mai 2019 22:24:23 MESZ schrieb Vladimir Sitnikov <si...@gmail.com>:
>Felix>I like to find them in the current repo I am working on and think
>that
>Felix>searching historic versions is so much easier in git than in svn,
>but
>Felix>you are of course right, that I could find them in the svn repo
>(given
>Felix>that we both think it will stay available as read only).
>
>There's a middle ground: we could have *two* Git repositories.
>The one with just the minimum set of required branches/tags (==used for
>main development).
>Another one could hold extra tags/branches. So the ones who are
>interested
>in those could fetch from that repo.
>
>Then mainline repo is not cluttered by outdated branches/tags, and you
>can
>still have all the refs in your working copy.
>
>However that might be an overkill since I don't really imagine much
>good
>from browsing historical "test" branches.
I think that would be overkill.
Felix
>
>Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Just in case, here's how repository looks like with the reduced set of
branches/tags:
https://github.com/vlsi/jmeter-git-cleanup-result
The logs are here (the removed files are listed there as well):
https://github.com/vlsi/jmeter-git-cleanup-result/tree/cleanup_log
If I keep just the very last version of each png, then .git reduces down to
40MiB (from 80).
That is nice taking into account that current .git takes 200MiB
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>I like to find them in the current repo I am working on and think that
Felix>searching historic versions is so much easier in git than in svn, but
Felix>you are of course right, that I could find them in the svn repo (given
Felix>that we both think it will stay available as read only).
There's a middle ground: we could have *two* Git repositories.
The one with just the minimum set of required branches/tags (==used for
main development).
Another one could hold extra tags/branches. So the ones who are interested
in those could fetch from that repo.
Then mainline repo is not cluttered by outdated branches/tags, and you can
still have all the refs in your working copy.
However that might be an overkill since I don't really imagine much good
from browsing historical "test" branches.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 28.05.19 um 21:44 schrieb Vladimir Sitnikov:
> Felix> I find those historic documents valuable
>
> What's the use case?
> It is sufficient that the files are present in SVN, isn'it?
I like to find them in the current repo I am working on and think that
searching historic versions is so much easier in git than in svn, but
you are of course right, that I could find them in the svn repo (given
that we both think it will stay available as read only).
>
> Felix> so if it is not too much trouble, I would keep them.
>
> It is not a trouble to keep them in SVN.
>
> However we don't want to clutter UI (e.g. GitHub branch selector) with
> tons of outdated branches when there's just one or two live ones. It
> is sad that Git has no notion of 'hidden' branches/tags.
I will not fight over this. I can work around such clutter, but it seems
you are more eager to remove them, then I am keen on keeping them. And
you are doing all the work and I am just a bystander.
Felix
P.S.: my reply was meant to be sent to the dev list and your responses
seem valuable, so I will steer this back to the original discussion
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix> Are they contributing much in size to the git repo?
They do not contribute much, however they do cluttter the output of
commands that list tags/branches
They do complicate history browsing since they sometimes have arcane
branching order.
I guess the rest of repository size is consumed by pdf/odt documents.
Do we still want to keep history for those? For instance, we could drop
historic editions of those binary files. Or we could drop the files and
replace them with some asciidoc (which is simpler to review and diff
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 28.05.19 um 19:00 schrieb Vladimir Sitnikov:
> There is a couple of branches which should probably be removed (just to
> avoid clutter):
> java1.5_prototype-was_trunk
> testbeans_experimental_branch
> test (cleanup script does remove "test" tag, however there is a "test"
> branch as well)
> HC4
>
> I think it makes sense to remove the following tags as well:
> JMeter1_0b1
> Root_rel-2-1
> Root_rel-3-1
> Root_testbeans_experimental_branch
> apache
> avendor
> initial
> jmeter1_5
> jmeter1_7
> jmeter_1_0
> jmeter_1_3
> latest
> latest-2-1
> latest-rel-2-1
> merge-2-0
> merge-2-1
> pre_properties
> rel-2_0_0
> rel-2_0_1
> rel-2_0_2
> rel-2_0_3
> rel-2_1
> release2-1a
> sas_checkpoint
> start_refactorings
>
> Any thoughts on dropping the above listed tags/branches from git repo as
> well?
Are they contributing much in size to the git repo? I would rather keep
most of those tags. Someone seems to have spend thoughts and work on
generating those tags. Let us value that work by keeping the tags if
they don't harm us.
Felix
>
> The following tags seem to be worth keeping:
> v1_7_1
> v1_7_1a
> v1_7_3
> v1_8
> v1_8_1
> v1_9
> v1_9_1
> v2_10
> v2_10_RC1
> v2_10_RC2
> v2_11
> v2_11_RC1
> v2_11_RC2
> v2_12
> v2_12_RC1
> v2_12_RC2
> v2_13
> v2_13_RC1
> v2_13_RC2
> v2_1_1
> v2_2
> v2_3
> v2_3_1
> v2_3_2
> v2_3_3
> v2_3_3_RC2
> v2_3_4
> v2_3_4_RC3
> v2_4
> v2_5
> v2_5_1
> v2_5_1_RC3
> v2_5_RC3
> v2_6
> v2_6_RC1
> v2_6_RC2
> v2_6_testRCtemp
> v2_7
> v2_7_RC1
> v2_7_RC2
> v2_7_RC3
> v2_8
> v2_8_RC1
> v2_8_RC2
> v2_9
> v2_9_RC1
> v2_9_RC2
> v2_9_RC3
> v3_0
> v3_0_RC1
> v3_0_RC2
> v3_0_RC3
> v3_0_RC4
> v3_0_RC5
> v3_1
> v3_1_RC1
> v3_1_RC2
> v3_1_RC3
> v3_1_RC4
> v3_2
> v3_2_RC1
> v3_2_RC2
> v3_2_RC3
> v3_3
> v3_3_RC1
> v4_0
> v4_0_RC1
> v4_0_RC2
> v4_0_RC3
> v4_0_RC4
> v4_0_RC5
> v4_0_RC6
> v4_0_RC7
> v5_0
> v5_0_RC1
> v5_0_RC2
> v5_1
> v5_1_1
> v5_1_1_RC1
> v5_1_RC1
> v5_1_RC2
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir>So I suggest to drop old "docs" branches as well. Any objections?
In other words, the only branch we need to keep is "trunk" (which becomes
"master")
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
I suggest we don't really modify SVN.
That would save us from losing data.
If you are perfectly sure we no longer need some of SVN tags/branches, then
go ahead and remove them.
I just think it makes little sense to analyze and cleanup SVN repository,
and there's a risk of removing something important.
If you think you can cleanup SVN within a day, then please do that.
Otherwise I don't want to be blocked by a mysterious SVN cleanup.
Git cleanup is just fine because we would have SVN as a backup.
I've updated the script and resulting repo.
----
The next question is "docs-*" branches in git repository.
I'm not sure we need those branches.
Those branches do not harm much, but I don't think they add value either.
Are we going to release old documentation from git sources?
I don't think so.
So I suggest to drop old "docs" branches as well. Any objections?
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
There's much too much change going on here.
I suggest we tidy up SVN before doing the conversion.
On Tue, 28 May 2019 at 18:09, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> There is a couple of branches which should probably be removed (just to
> avoid clutter):
> java1.5_prototype-was_trunk
> testbeans_experimental_branch
> test (cleanup script does remove "test" tag, however there is a "test"
> branch as well)
> HC4
>
> I think it makes sense to remove the following tags as well:
> JMeter1_0b1
> Root_rel-2-1
> Root_rel-3-1
> Root_testbeans_experimental_branch
> apache
> avendor
> initial
> jmeter1_5
> jmeter1_7
> jmeter_1_0
> jmeter_1_3
> latest
> latest-2-1
> latest-rel-2-1
> merge-2-0
> merge-2-1
> pre_properties
> rel-2_0_0
> rel-2_0_1
> rel-2_0_2
> rel-2_0_3
> rel-2_1
> release2-1a
> sas_checkpoint
> start_refactorings
>
> Any thoughts on dropping the above listed tags/branches from git repo as
> well?
>
> The following tags seem to be worth keeping:
> v1_7_1
> v1_7_1a
> v1_7_3
> v1_8
> v1_8_1
> v1_9
> v1_9_1
> v2_10
> v2_10_RC1
> v2_10_RC2
> v2_11
> v2_11_RC1
> v2_11_RC2
> v2_12
> v2_12_RC1
> v2_12_RC2
> v2_13
> v2_13_RC1
> v2_13_RC2
> v2_1_1
> v2_2
> v2_3
> v2_3_1
> v2_3_2
> v2_3_3
> v2_3_3_RC2
> v2_3_4
> v2_3_4_RC3
> v2_4
> v2_5
> v2_5_1
> v2_5_1_RC3
> v2_5_RC3
> v2_6
> v2_6_RC1
> v2_6_RC2
> v2_6_testRCtemp
> v2_7
> v2_7_RC1
> v2_7_RC2
> v2_7_RC3
> v2_8
> v2_8_RC1
> v2_8_RC2
> v2_9
> v2_9_RC1
> v2_9_RC2
> v2_9_RC3
> v3_0
> v3_0_RC1
> v3_0_RC2
> v3_0_RC3
> v3_0_RC4
> v3_0_RC5
> v3_1
> v3_1_RC1
> v3_1_RC2
> v3_1_RC3
> v3_1_RC4
> v3_2
> v3_2_RC1
> v3_2_RC2
> v3_2_RC3
> v3_3
> v3_3_RC1
> v4_0
> v4_0_RC1
> v4_0_RC2
> v4_0_RC3
> v4_0_RC4
> v4_0_RC5
> v4_0_RC6
> v4_0_RC7
> v5_0
> v5_0_RC1
> v5_0_RC2
> v5_1
> v5_1_1
> v5_1_1_RC1
> v5_1_RC1
> v5_1_RC2
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
There is a couple of branches which should probably be removed (just to
avoid clutter):
java1.5_prototype-was_trunk
testbeans_experimental_branch
test (cleanup script does remove "test" tag, however there is a "test"
branch as well)
HC4
I think it makes sense to remove the following tags as well:
JMeter1_0b1
Root_rel-2-1
Root_rel-3-1
Root_testbeans_experimental_branch
apache
avendor
initial
jmeter1_5
jmeter1_7
jmeter_1_0
jmeter_1_3
latest
latest-2-1
latest-rel-2-1
merge-2-0
merge-2-1
pre_properties
rel-2_0_0
rel-2_0_1
rel-2_0_2
rel-2_0_3
rel-2_1
release2-1a
sas_checkpoint
start_refactorings
Any thoughts on dropping the above listed tags/branches from git repo as
well?
The following tags seem to be worth keeping:
v1_7_1
v1_7_1a
v1_7_3
v1_8
v1_8_1
v1_9
v1_9_1
v2_10
v2_10_RC1
v2_10_RC2
v2_11
v2_11_RC1
v2_11_RC2
v2_12
v2_12_RC1
v2_12_RC2
v2_13
v2_13_RC1
v2_13_RC2
v2_1_1
v2_2
v2_3
v2_3_1
v2_3_2
v2_3_3
v2_3_3_RC2
v2_3_4
v2_3_4_RC3
v2_4
v2_5
v2_5_1
v2_5_1_RC3
v2_5_RC3
v2_6
v2_6_RC1
v2_6_RC2
v2_6_testRCtemp
v2_7
v2_7_RC1
v2_7_RC2
v2_7_RC3
v2_8
v2_8_RC1
v2_8_RC2
v2_9
v2_9_RC1
v2_9_RC2
v2_9_RC3
v3_0
v3_0_RC1
v3_0_RC2
v3_0_RC3
v3_0_RC4
v3_0_RC5
v3_1
v3_1_RC1
v3_1_RC2
v3_1_RC3
v3_1_RC4
v3_2
v3_2_RC1
v3_2_RC2
v3_2_RC3
v3_3
v3_3_RC1
v4_0
v4_0_RC1
v4_0_RC2
v4_0_RC3
v4_0_RC4
v4_0_RC5
v4_0_RC6
v4_0_RC7
v5_0
v5_0_RC1
v5_0_RC2
v5_1
v5_1_1
v5_1_1_RC1
v5_1_RC1
v5_1_RC2
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>We don't yet know that.
I'm sure it is OK to go.
The reasoning is simple:
1) The script adds NO new contents to the repository
2) The very same tool has already been used for other projects
sebb>Not so: we don't yet know what Infra have to say
They will wait for JMeter team to sign off that repository looks fine.
That is why we need to decide if repo looks good or not.
sebb>The issue is whether INFRA agree that is OK to delete any files during
sebb>the conversion.
INFRA-7464 <https://issues.apache.org/jira/browse/INFRA-7464> shows that
deleting files from Git history is perfectly possible.
Note: the very same files are present in SVN anyway, so we don't really
remove the files.
I do not see why do you push this "we don't know if removal is allowed" so
hard, even though
the very same files will be available in SVN.
Apparently the removal is allowed. Can we please stop spending time on that
discussion?
Thank you.
sebb>It may be unlikely, but INFRA need to give their view
Can we just assume that INFRA is ok with the script and check the
repository contents from JMeter point of view?
sebb>So what else has been dropped from the output?
Please check
https://github.com/vlsi/jmeter-git-cleanup/blob/c97efc513e121a88a77a193ff54c4a3fa9d38462/run.sh
script.
It lists the exact things that are removed.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Tue, 28 May 2019 at 15:48, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb>Infra OK with dropping files during conversion?
>
> As you can see, the very same bfg.jar has already been used to cleanup the
> repository size: https://issues.apache.org/jira/browse/INFRA-7464
> I believe that makes the cleanup approach perfectly viable.
Note that those JIRAs had agreement from Infra.
> In other words, none of your "serious enough" issues hold anymore.
Not so: we don't yet know what Infra have to say.
> sebb>I don't know whether there are other issues with the repo.
>
> Apparently INFRA does not know which files are important and which are not
> for JMeter project, so they won't be able to tell if the script removes
> more than necessary.
The issue is whether INFRA agree that is OK to delete any files during
the conversion.
We don't yet know that.
> On the other hand, the script is straightforward, and it uses well-known
> tools
rm -rf is a well-known tool; what matters is how the tool is used and
the end result.
> so it is very unlikely INFRA would deny the use of that script.
It may be unlikely, but INFRA need to give their view on the proposed
conversion process.
> That being said, we can just proceed with the analysis of
> https://github.com/vlsi/jmeter-git-cleanup-result repository.
>
> Note: in the meantime I updated the conversion script so it no longer
> removes png files from xdocs folder. "cleanup-result" repository is updated
> as well.
So what else has been dropped from the output?
I think you need to update the JIRA with the hashes of the tool and
the repo so Infra have a stable base to look at.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>Infra OK with dropping files during conversion?
As you can see, the very same bfg.jar has already been used to cleanup the
repository size: https://issues.apache.org/jira/browse/INFRA-7464
I believe that makes the cleanup approach perfectly viable.
In other words, none of your "serious enough" issues hold anymore.
sebb>I don't know whether there are other issues with the repo.
Apparently INFRA does not know which files are important and which are not
for JMeter project, so they won't be able to tell if the script removes
more than necessary.
On the other hand, the script is straightforward, and it uses well-known
tools, so it is very unlikely INFRA would deny the use of that script.
That being said, we can just proceed with the analysis of
https://github.com/vlsi/jmeter-git-cleanup-result repository.
Note: in the meantime I updated the conversion script so it no longer
removes png files from xdocs folder. "cleanup-result" repository is updated
as well.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> I meant that the Git repo would lose the SVN history.
sebb>I did not look at the git repo any further once I had noted those two
sebb>because I thought they were serious enough
I've created https://issues.apache.org/jira/browse/INFRA-18499
I'm sure the removal of obsolete files is fine though.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 27 May 2019 at 21:59, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> -1, because that loses all the SVN history.
>
> I'm afraid you are wrong. Could you please clarify what do you mean?
I meant that the Git repo would lose the SVN history.
> Note: SVN repository is NEVER killed. It would still be around in read-only
> mode.
Obviously.
> sebb> AFAICT, there is no way to find historic SVN revisions in the
> cleaned-up repo
>
> SVN revision numbers (and branch names) are present in commit messages.
> For instance:
> https://github.com/vlsi/jmeter-git-cleanup-result/commit/561048407dab3afcfd880b168fabdeeeabb8422d
>
> There are two references:
> 1) Reference to SVN: git-svn-id:
> https://svn.apache.org/repos/asf/jmeter/trunk@1860117
> 2) Reference to "old Git mirror": Former-commit-id:
> 184a9d5a5ea8badd1b1616dad0ff2f327a9b0756
OK, not sure how I missed that.
> sebb> Also, where in the history are the files that have been deleted?
>
> The deleted files are still available via SVN read-only mirror.
But not in the Git history.
I think Infra need to agree to that.
> sebb> I think INFRA need to review the script to make sure that it preserves
> sebb> all necessary provenance.
>
> Great note, indeed. That is up to them though. I don't think we can do much
> here.
We need to ask Infra to agree the process.
> sebb> -1 to combining Git with Gradle for the reasons stated above.
>
> What about the use of https://github.com/vlsi/jmeter-git-cleanup-result for
> Git?
> It looks like the only your concerns were "missing SVN revisions" (which
> are present) and "lost files" (which will be available through read-only
> SVN).
> I read that as you have no concerns regarding jmeter-git-cleanup-result
> besides the one that INFRA should check that somehow.
No, that is not what I wrote.
I noted two issues with the Git repo.
I did not look at the git repo any further once I had noted those two
because I thought they were serious enough for it to be pointless to
check further.
One issue (svn ids) was invalid, but the other still applies, i.e. is
Infra OK with dropping files during conversion?
I don't know whether there are other issues with the repo.
A separate matter is that I believe Infra should review the script
that was used to create the repo in case they have any concerns.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> -1, because that loses all the SVN history.
I'm afraid you are wrong. Could you please clarify what do you mean?
Note: SVN repository is NEVER killed. It would still be around in read-only
mode.
sebb> AFAICT, there is no way to find historic SVN revisions in the
cleaned-up repo
SVN revision numbers (and branch names) are present in commit messages.
For instance:
https://github.com/vlsi/jmeter-git-cleanup-result/commit/561048407dab3afcfd880b168fabdeeeabb8422d
There are two references:
1) Reference to SVN: git-svn-id:
https://svn.apache.org/repos/asf/jmeter/trunk@1860117
2) Reference to "old Git mirror": Former-commit-id:
184a9d5a5ea8badd1b1616dad0ff2f327a9b0756
sebb> Also, where in the history are the files that have been deleted?
The deleted files are still available via SVN read-only mirror.
sebb> I think INFRA need to review the script to make sure that it preserves
sebb> all necessary provenance.
Great note, indeed. That is up to them though. I don't think we can do much
here.
sebb> -1 to combining Git with Gradle for the reasons stated above.
What about the use of https://github.com/vlsi/jmeter-git-cleanup-result for
Git?
It looks like the only your concerns were "missing SVN revisions" (which
are present) and "lost files" (which will be available through read-only
SVN).
I read that as you have no concerns regarding jmeter-git-cleanup-result
besides the one that INFRA should check that somehow.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 27 May 2019 at 22:19, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> I've moved this bit from "Gradle" thread to keep things separated.
>
> sebb> There is no way to map SVN revisions to Git commits, also the history
> sebb> of deletions is lost
>
> As I said, SVN revisions are present in Git commit messages.
> Why do you think "there is no way to map"?
Already agreed that was my error.
> sebb>the history
> sebb> of deletions is lost
>
> The history is NOT lost. The deleted files are deleted in every git commit.
> It happens as if they were never added.
>
> Old history (unmodified) can still be available via SVN (with all the files
> preset), and/or via "old git mirror".
The point is that the history of deletions is not present in the ongoing repo.
That needs to be agreed with Infra.
> sebb>I think we need to get agreement from Infra on any conversion which
> sebb>does not use the standard process, in case the process does not meet
> sebb>the requirements for provenance etc
>
> On contrary. What I suggest IS the standard process.
Yes and no. Overall it is the same, but the detail is different.
> Please check recent migration of Apache Tomcat project:
> https://issues.apache.org/jira/browse/INFRA-17887
>
> It is exactly as I suggest: infra disables svn->git sync, they make gitbox
> repository writable, then we agree to stop committing while migration is
> performed, then we review, then we continue.
Yes, but what is not the same is how the migration is performed.
It's the migration strategy that I am concerned with.
That needs to be agreed with Infra.
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've moved this bit from "Gradle" thread to keep things separated.
sebb> There is no way to map SVN revisions to Git commits, also the history
sebb> of deletions is lost
As I said, SVN revisions are present in Git commit messages.
Why do you think "there is no way to map"?
sebb>the history
sebb> of deletions is lost
The history is NOT lost. The deleted files are deleted in every git commit.
It happens as if they were never added.
Old history (unmodified) can still be available via SVN (with all the files
preset), and/or via "old git mirror".
sebb>I think we need to get agreement from Infra on any conversion which
sebb>does not use the standard process, in case the process does not meet
sebb>the requirements for provenance etc
On contrary. What I suggest IS the standard process.
Please check recent migration of Apache Tomcat project:
https://issues.apache.org/jira/browse/INFRA-17887
It is exactly as I suggest: infra disables svn->git sync, they make gitbox
repository writable, then we agree to stop committing while migration is
performed, then we review, then we continue.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 27 May 2019 at 21:48, Philippe Mouawad
<ph...@gmail.com> wrote:
>
> Hi sebb,
>
> Few questions below.
>
> Regards
>
> On Mon, May 27, 2019 at 10:32 PM sebb <se...@gmail.com> wrote:
>
> > On Mon, 27 May 2019 at 21:19, Vladimir Sitnikov
> > <si...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > This thread has been idle for a while.
> > >
> > > The results (re move to Gradle) so far are:
> > > +1 (binding) Philippe Mouawad
> > > ++1 (binding) Vladimir Sitnikov
> > > +1 (binding) Antonio Gomes Rodrigues
> > > +1 Andrey Pokhilko
> > > +1 Graham Russell
> > > +1 (binding) Milamber
> > >
> > > No vetos detected.
> > >
> > > That is there's a consensus to use Git for source code.
> >
> > OK
> >
> > > As you might know I have created a script to cleanup the repository:
> > > https://github.com/vlsi/jmeter-git-cleanup
> > > I just re-ran the script, and here's the result:
> > > https://github.com/vlsi/jmeter-git-cleanup-result
> >
> > -1, because that loses all the SVN history.
> >
>
> Can you clarify this ?
> What is lost exactly ?
>
See the next two sentences below.
>
> > AFAICT, there is no way to find historic SVN revisions in the cleaned-up
> > repo
> >
> > Also, where in the history are the files that have been deleted?
> >
> > > If no objections, I can start migration from SVN to Git.
> > > The process is as follows: INFRA uses the provided repo and copies the
> > > result to /apache/jmeter.git, and setups the infrastructure accordingly.
> >
> > I think INFRA need to review the script to make sure that it preserves
> > all necessary provenance.
> >
> > > Note: I think it makes sense to do Ant+SVN -> Gradle+Git as a single
> > > change. That would simplify the evaluation and review (both repositories
> > > would be perfectly buildable).
> > > If we go with Ant+SVN -> Ant+Git -> Gradle+Git route, then the
> > intermediate
> > > Ant+Git would probably contain its own bugs, and we would just spend time
> > > on analyzing/fixing those.
> >
> > That can be tested now, by using the existing GitHub read-only mirror.
> >
> > > However I'm open to suggestions. If there are reasons to move from SVN to
> > > Git first, it can definitely be done assuming we don't add Git support to
> > > build.xml.
> > >
> > > If no objections received, I'll proceed with Ant+SVN -> Gradle+Git
> > approach
> > > as vote for Gradle resolves.
> >
> > -1 to combining Git with Gradle for the reasons stated above.
> >
> > > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi sebb,
Few questions below.
Regards
On Mon, May 27, 2019 at 10:32 PM sebb <se...@gmail.com> wrote:
> On Mon, 27 May 2019 at 21:19, Vladimir Sitnikov
> <si...@gmail.com> wrote:
> >
> > Hi,
> >
> > This thread has been idle for a while.
> >
> > The results (re move to Gradle) so far are:
> > +1 (binding) Philippe Mouawad
> > ++1 (binding) Vladimir Sitnikov
> > +1 (binding) Antonio Gomes Rodrigues
> > +1 Andrey Pokhilko
> > +1 Graham Russell
> > +1 (binding) Milamber
> >
> > No vetos detected.
> >
> > That is there's a consensus to use Git for source code.
>
> OK
>
> > As you might know I have created a script to cleanup the repository:
> > https://github.com/vlsi/jmeter-git-cleanup
> > I just re-ran the script, and here's the result:
> > https://github.com/vlsi/jmeter-git-cleanup-result
>
> -1, because that loses all the SVN history.
>
Can you clarify this ?
What is lost exactly ?
> AFAICT, there is no way to find historic SVN revisions in the cleaned-up
> repo
>
> Also, where in the history are the files that have been deleted?
>
> > If no objections, I can start migration from SVN to Git.
> > The process is as follows: INFRA uses the provided repo and copies the
> > result to /apache/jmeter.git, and setups the infrastructure accordingly.
>
> I think INFRA need to review the script to make sure that it preserves
> all necessary provenance.
>
> > Note: I think it makes sense to do Ant+SVN -> Gradle+Git as a single
> > change. That would simplify the evaluation and review (both repositories
> > would be perfectly buildable).
> > If we go with Ant+SVN -> Ant+Git -> Gradle+Git route, then the
> intermediate
> > Ant+Git would probably contain its own bugs, and we would just spend time
> > on analyzing/fixing those.
>
> That can be tested now, by using the existing GitHub read-only mirror.
>
> > However I'm open to suggestions. If there are reasons to move from SVN to
> > Git first, it can definitely be done assuming we don't add Git support to
> > build.xml.
> >
> > If no objections received, I'll proceed with Ant+SVN -> Gradle+Git
> approach
> > as vote for Gradle resolves.
>
> -1 to combining Git with Gradle for the reasons stated above.
>
> > Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 27 May 2019 at 21:19, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Hi,
>
> This thread has been idle for a while.
>
> The results (re move to Gradle) so far are:
> +1 (binding) Philippe Mouawad
> ++1 (binding) Vladimir Sitnikov
> +1 (binding) Antonio Gomes Rodrigues
> +1 Andrey Pokhilko
> +1 Graham Russell
> +1 (binding) Milamber
>
> No vetos detected.
>
> That is there's a consensus to use Git for source code.
OK
> As you might know I have created a script to cleanup the repository:
> https://github.com/vlsi/jmeter-git-cleanup
> I just re-ran the script, and here's the result:
> https://github.com/vlsi/jmeter-git-cleanup-result
-1, because that loses all the SVN history.
AFAICT, there is no way to find historic SVN revisions in the cleaned-up repo
Also, where in the history are the files that have been deleted?
> If no objections, I can start migration from SVN to Git.
> The process is as follows: INFRA uses the provided repo and copies the
> result to /apache/jmeter.git, and setups the infrastructure accordingly.
I think INFRA need to review the script to make sure that it preserves
all necessary provenance.
> Note: I think it makes sense to do Ant+SVN -> Gradle+Git as a single
> change. That would simplify the evaluation and review (both repositories
> would be perfectly buildable).
> If we go with Ant+SVN -> Ant+Git -> Gradle+Git route, then the intermediate
> Ant+Git would probably contain its own bugs, and we would just spend time
> on analyzing/fixing those.
That can be tested now, by using the existing GitHub read-only mirror.
> However I'm open to suggestions. If there are reasons to move from SVN to
> Git first, it can definitely be done assuming we don't add Git support to
> build.xml.
>
> If no objections received, I'll proceed with Ant+SVN -> Gradle+Git approach
> as vote for Gradle resolves.
-1 to combining Git with Gradle for the reasons stated above.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Hi,
This thread has been idle for a while.
The results (re move to Gradle) so far are:
+1 (binding) Philippe Mouawad
++1 (binding) Vladimir Sitnikov
+1 (binding) Antonio Gomes Rodrigues
+1 Andrey Pokhilko
+1 Graham Russell
+1 (binding) Milamber
No vetos detected.
That is there's a consensus to use Git for source code.
As you might know I have created a script to cleanup the repository:
https://github.com/vlsi/jmeter-git-cleanup
I just re-ran the script, and here's the result:
https://github.com/vlsi/jmeter-git-cleanup-result
If no objections, I can start migration from SVN to Git.
The process is as follows: INFRA uses the provided repo and copies the
result to /apache/jmeter.git, and setups the infrastructure accordingly.
Note: I think it makes sense to do Ant+SVN -> Gradle+Git as a single
change. That would simplify the evaluation and review (both repositories
would be perfectly buildable).
If we go with Ant+SVN -> Ant+Git -> Gradle+Git route, then the intermediate
Ant+Git would probably contain its own bugs, and we would just spend time
on analyzing/fixing those.
However I'm open to suggestions. If there are reasons to move from SVN to
Git first, it can definitely be done assuming we don't add Git support to
build.xml.
If no objections received, I'll proceed with Ant+SVN -> Gradle+Git approach
as vote for Gradle resolves.
Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix>Well, disk space is cheap nowadays
The main improvement is:
A) network transfer. Often you just want to have a fresh clone, and 120 vs
60 mib transfer makes difference. It is especially the case when you know
that one half makes no sense :)
B) Git response times. Git local repo needs housekeeping, and extra objects
increase those timings.
C) less clutter in the repository simplifies historical analysis
Felix> When we look at it
again, we should really drop it. It is a nuisance at least to me
My current script drops docs/ from all the branches.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 23.02.19 um 23:06 schrieb Vladimir Sitnikov:
> As far as I see, we can have decent repository in case we massage
> current Git mirror.
> I've created a script for that: https://github.com/vlsi/jmeter-git-cleanup
Do you ever sleep?
>
> It takes a couple of minutes (provided there's pre-polulated
> jmeter_clone), and it produces the following:
> https://github.com/vlsi/jmeter-git-cleanup-result
> If you clone that, it transfers 120MiB, and working copy becomes
> 188MiB (53MiB sources + 135MiB for .git)
> For the reference, current .svn folder is 80MiB.
Well, disk space is cheap nowadays. And I really like to have the
complete history around and be able to switch in seconds between the
different commits.
> I've attached sample history around v4.0 which turns out to be
> perfectly flat.
I see no attachement.
>
> I did not remove/alter docs and/or javadocs, however it does look
> weird to store javadocs side by side with the code.
> Should I drop docs-x.y branches as well? What's the point with them?
> Apparently old docs branches will still live in SVN, however I think
> we should no longer create them.
We discussed dropping the docs folder some time ago, but were unsure,
whether it was needed somehow in the build process. When we look at it
again, we should really drop it. It is a nuisance at least to me, as I
don't bother to keep it up to date in between releases and I always have
to revert the changes in there before each commit.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
As far as I see, we can have decent repository in case we massage current
Git mirror.
I've created a script for that: https://github.com/vlsi/jmeter-git-cleanup
It takes a couple of minutes (provided there's pre-polulated jmeter_clone),
and it produces the following:
https://github.com/vlsi/jmeter-git-cleanup-result
If you clone that, it transfers 120MiB, and working copy becomes 188MiB
(53MiB sources + 135MiB for .git)
For the reference, current .svn folder is 80MiB.
I've attached sample history around v4.0 which turns out to be perfectly
flat.
I did not remove/alter docs and/or javadocs, however it does look weird to
store javadocs side by side with the code.
Should I drop docs-x.y branches as well? What's the point with them?
Apparently old docs branches will still live in SVN, however I think we
should no longer create them.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Sat, 23 Feb 2019 at 15:48, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> > > 3) Tags (e.g. version tags) are located at separate branches which
> > > complicates history browsing
> > Can you give an example of this? I don't get what you mean.
>
> Please find an attached gitk view of the current Git mirror.
>
> In case you are not familiar with output, commits grow from the bottom
> (just like regular trees do).
>
> It bothers me in multiple ways:
> 1) V5_1_RC1, v5_1_RC2, and v5_1 tags are placed OUTSIDE of the trunk
> history. In other words, if I browse "trunk" history alone, I don't
> see tags at all
> 2) It is quite obscure which repository state is represented by RC.
> 3) V4_0 tags seem to be a complete mess (see attached
> jmeter_v4_history.png). For instance, can you tell which commits are
> there between V4_0_RC2 and V4_0_RC4?
$ svn log https://svn.apache.org/repos/asf/jmeter/tags/v4_0_RC2 -v -l 1
------------------------------------------------------------------------
r1822462 | milamber | 2018-01-28 14:39:59 +0000 (Sun, 28 Jan 2018) | 1 line
Changed paths:
A /jmeter/tags/v4_0_RC2 (from /jmeter/trunk:1822461)
Tag for pre-release
------------------------------------------------------------------------
$ svn log https://svn.apache.org/repos/asf/jmeter/tags/v4_0_RC4 -v -l 1
------------------------------------------------------------------------
r1822613 | milamber | 2018-01-30 07:50:10 +0000 (Tue, 30 Jan 2018) | 1 line
Changed paths:
A /jmeter/tags/v4_0_RC4 (from /jmeter/trunk:1822612)
M /jmeter/tags/v4_0_RC4/build.xml
Tag for pre-release
------------------------------------------------------------------------
i.e.
v4_0_RC2 was created from jmeter/trunk:1822461
v4_0_RC4 was created from jmeter/trunk:1822612
From which you can work out what trunk changes were made between the two tags.
> Can you tell why V4_0_RC5 is not between V4_0_RC4 and V4_0_RC6?
The derivations as above are:
A /jmeter/tags/v4_0_RC5 (from /jmeter/trunk:1822958)
A /jmeter/tags/v4_0_RC6 (from /jmeter/trunk:1822964)
Seems to me that the tags *are* in the correct order in SVN.
If they are incorrect in git, then it seems to me that the conversion
to Git has failed to preserve history.
> We don't have lots of tags, so we could even "migrate" that manually,
> and it could be faster than trying to make that automatic.
> What do you think?
> A bit of a side question: what is the purpose of having docs-x.y branches?
> What is the purpose of placing generated javadocs to docs-x.y branch?
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> But my reading of what you wrote was that master would be set to 5.1
sebb> at some point, i.e. it was not an atomic change of snapshot version.
I suggest an atomic update from 5.1-SNAPSHOT to 5.2-SNAPSHOT while 5.1
is there in the middle.
I'm sure that closes the discussion.
sebb>As already noted, I think it's going to be tricky to separate the two.
Ok, I see your point.
sebb>But we don't want any such branches to have any source code update
It might still be useful for back-patching CVEs.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Tue, 26 Feb 2019 at 09:53, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> We should clear up SVN before doing any conversion to Git.
>
> Which cleanup do you mean?
Deleting any unnecessary tags; I've already done that for the test tags.
> sebb> A person looking at the repo will see that there is 5.2-SNAPSHOT and
> sebb> naturally assume it is more recent than 5.1-SNAPSHOT.
>
> That is true, however it does not harm much since exactly the same
> person would check website as well.
> On the other hand, automatic build that fetches 5.1-SNAPSHOT would
> never be confused by 5.2-SNAPSHOT.
>
> sebb>otherwise there are issues with CI and potential confusion over what
> sebb>is the release
>
> Which CI issues?
> Can you please pin-point at least a single one?
I've already answered this many times.
> master branch is advanced *atomically* from 5.1-SNAPSHOT to
> 5.2-SNAPSHOT even though there's 5.1 in-between.
> What CI issues could happen in that case? I truly don't see.
If master changes directly from 5.1-SNAPSHOT to 5.2-SNAPSHOT, then I
agree there is no problem.
But my reading of what you wrote was that master would be set to 5.1
at some point, i.e. it was not an atomic change of snapshot version.
> sebb>and local builds will generate what appear to be releases
> sebb>from the version.
>
> In ideal world, builds are 100% reproducible. In other words, one
> should be able to reproduce the build by performing exactly the same
> steps.
> If a person manually checks out master branch at random, commits and
> deploys to whatever repository, we can't really prevent that.
But we can prevent that build from having a release version.
> Can you please explain how SVN tags prevents that?
>
> A person might checkout SVN tag, perform build which will generate
> what "appear to be release".
That's OK, because it is using the correct source for the build.
> Even though "release versions" are placed in SVN tags, one can export
> that tag and "local builds will generate what appear to be releases".
> I don't really see why you think placing release versions at tags only
> somehow magically resolves the issue.
Because a tag is known to be a specific version and tags are not the
default download from a repo.
> Vladimir> My point is docs-x.y violates POLA and release-x.y does not.
> sebb>I disagree, because docs-x.y is not a release.
>
> I see. You don't see the full picture then.
> I suggest we have release-x.y branches that would be *release*
> branches with source code.
But we don't want any such branches to have any source code updates.
The point about the docs branch is that it is only intended for doc updates.
However it needs more than just the xdocs files in order to build.
> The documentation artifacts would be put to a separate repository (jmeter-site).
The xdocs files which are used to build the site are also used to
build the Help files.
We don't want duplicate copies in different repos.
As already noted, I think it's going to be tricky to separate the two.
> That would make docs-x.y branches obsolete and it would make source
> code easier to follow.
>
> sebb>docs-for-release-x.y
>
> PS. "docs-for-release-x.y" name would still violate POLA if it
> contains more than the documentation.
It has to contain more than the documentation, as it needs various
support files to build the docs
And it needs the sources if it proved necessary to rebuild the Javadocs
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> We should clear up SVN before doing any conversion to Git.
Which cleanup do you mean?
sebb> A person looking at the repo will see that there is 5.2-SNAPSHOT and
sebb> naturally assume it is more recent than 5.1-SNAPSHOT.
That is true, however it does not harm much since exactly the same
person would check website as well.
On the other hand, automatic build that fetches 5.1-SNAPSHOT would
never be confused by 5.2-SNAPSHOT.
sebb>otherwise there are issues with CI and potential confusion over what
sebb>is the release
Which CI issues?
Can you please pin-point at least a single one?
master branch is advanced *atomically* from 5.1-SNAPSHOT to
5.2-SNAPSHOT even though there's 5.1 in-between.
What CI issues could happen in that case? I truly don't see.
sebb>and local builds will generate what appear to be releases
sebb>from the version.
In ideal world, builds are 100% reproducible. In other words, one
should be able to reproduce the build by performing exactly the same
steps.
If a person manually checks out master branch at random, commits and
deploys to whatever repository, we can't really prevent that.
Can you please explain how SVN tags prevents that?
A person might checkout SVN tag, perform build which will generate
what "appear to be release".
Even though "release versions" are placed in SVN tags, one can export
that tag and "local builds will generate what appear to be releases".
I don't really see why you think placing release versions at tags only
somehow magically resolves the issue.
Vladimir> My point is docs-x.y violates POLA and release-x.y does not.
sebb>I disagree, because docs-x.y is not a release.
I see. You don't see the full picture then.
I suggest we have release-x.y branches that would be *release*
branches with source code.
The documentation artifacts would be put to a separate repository (jmeter-site).
That would make docs-x.y branches obsolete and it would make source
code easier to follow.
sebb>docs-for-release-x.y
PS. "docs-for-release-x.y" name would still violate POLA if it
contains more than the documentation.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Tue, 26 Feb 2019 at 05:52, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> Given that SVN history for tags/testhead
>
> We have agreed that we don't need the tags, so let's just drop them
> and close the discussion.
> Note: I don't care if the tags will be removed from SVN or not.
We should clear up SVN before doing any conversion to Git.
> sebb> No, it's just the reverse, because 5.2-SNAPSHOT is later than
> sebb> 5.1-SNAPSHOT so it 'hides' the later builds which are tagged
> sebb> 5.1-SNAPSHOT.
>
> Suppose a client is using 5.1-SNAPSHOT version:
> <dependency>...<artifactId>ApacheJMeter_core</artifactId><version>5.1-SNAPSHOT</version>
> Then 5.2-SNAPSHOT won't 'hide' it or whatever.
> The client will use 5.1-SNAPSHOT no matter whatever other versions
> (snapshot or non-snapshot) are released.
>
> What do you mean by 'hides'?
A person looking at the repo will see that there is 5.2-SNAPSHOT and
naturally assume it is more recent than 5.1-SNAPSHOT.
> > > 5.1-SNAPSHOT
> > > 5.1-SNAPSHOT
> > > 5.2 <- this commit is tagged with v5.2
> > > 5.3-SNAPSHOT
> > > 5.3-SNAPSHOT
> >
> sebb> The above is wrong - what happened to 5.2-SNAPSHOT?
>
> For instance: it was agreed to release the version as 5.2 even though
> snapshot was named 5.1-SNAPSHOT.
AFAIK, we never do that; 5.2 is released from 5.2-SNAPSHOT
> Technically speaking I intended to list 5.2-SNAPSHOT instead of 5.1-SNAPSHOT.
Understood.
> However both histories are perfectly fine even though
> 5.1-SNAPSHOT->5.2 is slightly confusing.
OK, except I disagree that trunk/master should ever be a release version.
> My point is at some (single!) point in time master branch should have
> a release version.
This is where we disagree - it should never have a release version
otherwise there are issues with CI and potential confusion over what
is the release.
> sebb>At this point master has a release version, which is a no-no as
> sebb>already explained.
>
> You have never explained why it is wrong to have a single commit with
> a release version in a master branch.
> Would you please elaborate?
I already explained this several times: any CI builds create what
looks like a release version.
Also, if anyone exports the master at that point, it appears to be a
release, and local builds will generate what appear to be releases
from the version.
Violates POLA.
> sebb> It's documented on the Wiki
>
> My point is docs-x.y violates POLA and release-x.y does not.
I disagree, because docs-x.y is not a release.
It is the docs for the release-x.y, so it should be named something like
docs-for-release-x.y
in order to be obvious.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> Given that SVN history for tags/testhead
We have agreed that we don't need the tags, so let's just drop them
and close the discussion.
Note: I don't care if the tags will be removed from SVN or not.
sebb> No, it's just the reverse, because 5.2-SNAPSHOT is later than
sebb> 5.1-SNAPSHOT so it 'hides' the later builds which are tagged
sebb> 5.1-SNAPSHOT.
Suppose a client is using 5.1-SNAPSHOT version:
<dependency>...<artifactId>ApacheJMeter_core</artifactId><version>5.1-SNAPSHOT</version>
Then 5.2-SNAPSHOT won't 'hide' it or whatever.
The client will use 5.1-SNAPSHOT no matter whatever other versions
(snapshot or non-snapshot) are released.
What do you mean by 'hides'?
> > 5.1-SNAPSHOT
> > 5.1-SNAPSHOT
> > 5.2 <- this commit is tagged with v5.2
> > 5.3-SNAPSHOT
> > 5.3-SNAPSHOT
>
sebb> The above is wrong - what happened to 5.2-SNAPSHOT?
For instance: it was agreed to release the version as 5.2 even though
snapshot was named 5.1-SNAPSHOT.
Technically speaking I intended to list 5.2-SNAPSHOT instead of 5.1-SNAPSHOT.
However both histories are perfectly fine even though
5.1-SNAPSHOT->5.2 is slightly confusing.
My point is at some (single!) point in time master branch should have
a release version.
sebb>At this point master has a release version, which is a no-no as
sebb>already explained.
You have never explained why it is wrong to have a single commit with
a release version in a master branch.
Would you please elaborate?
sebb> It's documented on the Wiki
My point is docs-x.y violates POLA and release-x.y does not.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 25 Feb 2019 at 20:57, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> What do you mean by "root commit"?
>
> In Git every commit has 0..n parent commits.
> The most typical case is 1 parent which represents a simple history like a->b->c
> Two or more parent commits mean we deal with a merge commit.
>
> Commit can have 0 parents, and it means it is "Initial" commit. That
> is the one that does not have previous history.
> Git repositories can have multiple unrelated histories (e.g. multiple
> root commits, and each one could evolve into its own unrelated
> history)
Given that SVN history for tags/testhead and tags/test are basically
identical, I think that must be a problem in the SVN->Git conversion.
Here is the commit that created test:
A /jakarta/jmeter/tags/test (from /jakarta/jmeter/tags/v2_5_RC3:1167593)
And testhead:
A /jakarta/jmeter/tags/testhead (from /jakarta/jmeter/tags/v2_5_RC3:1167595)
This look identical to me apart from the source revision.
> sebb> Or 5.2-SNAPSHOT may never be replaced, if the next version is
> 6.0-SNAPSHOT.
>
> See: 5.2-SNAPSHOT will likely be replaced provided the subsequent
> version is 5.2.
Eventually. But it may take a while.
Meanwhile there is a spurious 5.2-snapshot which is older than the
5.1-snapshots.
But if there is no further minor version, it won't be replaced.
> On the other hand, current build.xml produces 5.1-SNAPSHOT, and it is
> extremely unlikely that we would ever produce 5.1-SNAPSHOT for a good
> reason.
I don't understand.
> That means 5.1-SNAPSHOT is broken forever unless someone redeploys a
> proper 5.1-SNAPSHOT (the one that does not include bits of 5.2), or
> removes 5.1-SNAPSHOT from the repository.
If the build.xml is not updated in a timely fashion, then I agree that
5.1-SNAPSHOT may contain some bits of 5.2.
But that does not matter, because once the version is updated to
5.2-SNAPSHOT, that will become the latest snapshot.
If the release procedures are followed, there should be no spurious
commits in the snapshot.
> Both cases are bad, however current 5.1-SNAPSHOT is worse than a
> theoretical 5.2-SNAPSHOT.
No, it's just the reverse, because 5.2-SNAPSHOT is later than
5.1-SNAPSHOT so it 'hides' the later builds which are tagged
5.1-SNAPSHOT.
Remember that the version has to be down-dated if the release fails.
> However, there's no point in discussing that. I think you missed my
> point: I suggest to create release branches, and set non-snapshot
> version there.
This is basically what happens currently, except we use SVN tags.
> Then:
> 1) master would not be affected by release branches
> 2) As soon as release branch settles down, master is promoted to the
> relevant commit (non-snapshot one)
At this point master has a release version, which is a no-no as
already explained.
> 3) Then we increase the version and add SNAPSHOT again to the master branch.
>
> In other words, master branch history would look like
> 5.1-SNAPSHOT
> 5.1-SNAPSHOT
> 5.2 <- this commit is tagged with v5.2
> 5.3-SNAPSHOT
> 5.3-SNAPSHOT
The above is wrong - what happened to 5.2-SNAPSHOT?
> sebb> The following are SVN test commits, and could be deleted now
>
> Ok, I've added them to the script.
I think they should just be removed from SVN.
> sebb> Again, IMO it's too late to change this now
>
> I don't think it's to late to change branch names.
> At least, we can start using release-X.Y for release branches.
OK for new branches.
But it's too late to change existing branch names - that would be
confusing, and there may be references to them.
> Frankly speaking, I was puzzled by docs-x.y naming for the branch that
> contained both sources, docs and javadocs.
It's documented on the Wiki:
https://wiki.apache.org/jmeter/ReleaseCreation
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> What do you mean by "root commit"?
In Git every commit has 0..n parent commits.
The most typical case is 1 parent which represents a simple history like a->b->c
Two or more parent commits mean we deal with a merge commit.
Commit can have 0 parents, and it means it is "Initial" commit. That
is the one that does not have previous history.
Git repositories can have multiple unrelated histories (e.g. multiple
root commits, and each one could evolve into its own unrelated
history)
sebb> Or 5.2-SNAPSHOT may never be replaced, if the next version is
6.0-SNAPSHOT.
See: 5.2-SNAPSHOT will likely be replaced provided the subsequent
version is 5.2.
On the other hand, current build.xml produces 5.1-SNAPSHOT, and it is
extremely unlikely that we would ever produce 5.1-SNAPSHOT for a good
reason.
That means 5.1-SNAPSHOT is broken forever unless someone redeploys a
proper 5.1-SNAPSHOT (the one that does not include bits of 5.2), or
removes 5.1-SNAPSHOT from the repository.
Both cases are bad, however current 5.1-SNAPSHOT is worse than a
theoretical 5.2-SNAPSHOT.
However, there's no point in discussing that. I think you missed my
point: I suggest to create release branches, and set non-snapshot
version there.
Then:
1) master would not be affected by release branches
2) As soon as release branch settles down, master is promoted to the
relevant commit (non-snapshot one)
3) Then we increase the version and add SNAPSHOT again to the master branch.
In other words, master branch history would look like
5.1-SNAPSHOT
5.1-SNAPSHOT
5.2 <- this commit is tagged with v5.2
5.3-SNAPSHOT
5.3-SNAPSHOT
sebb> The following are SVN test commits, and could be deleted now
Ok, I've added them to the script.
sebb> Again, IMO it's too late to change this now
I don't think it's to late to change branch names.
At least, we can start using release-X.Y for release branches.
Frankly speaking, I was puzzled by docs-x.y naming for the branch that
contained both sources, docs and javadocs.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 25 Feb 2019 at 18:24, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> The 5.2-SNAPSHOT builds will hang around unless manually deleted
>
> It will be superseded by CI automatically as soon as the vote passes and
> the version is incremented to 5.2-SNAPSHOT.
Yes - in general.
But this may take days, weeks or even months.
It has done in the past.
Or 5.2-SNAPSHOT may never be replaced, if the next version is 6.0-SNAPSHOT.
As I recall, there was an issue with the wrong snapshot being used
that led to the current process being introduced.
We've not had the issue since.
> 1) As far as I read the discussion, no-one really cares of the past tags,
That's not the case; past tags that relate to releases and release
votes are vital and must be preserved.
> so I'm fine with just leaving tag placement "as is".
>
> 2) I'm inclined to drop docs/ folder from the source repository. It should
> better be placed to the separate site repository.
Sounds OK, but might make it harder to build the site.
At present the source for the site is in the same directory tree as
the output, which means it can easily be found as a relative path.
If the output is in a different repo then it will be in a different
directory structure.
How do you get from one to the other?
I think this needs careful consideration.
> 3) I'm inclined to drop "test-bin" and "testhead" tags. The sad thing with
> "testhead" is that tag has its own "root commit" somehow.
What do you mean by "root commit"?
It looks just like the other test* tags to me.
> Those tags are not important anyway.
Agreed.
The following are SVN test commits, and could be deleted now:
tags/test
tags/test-bin
tags/test1157668
tags/testhead
> Then docs-x.y branches are pretty-much harmless. The only annoying thing is
> the number of the branches, however it is manageable.
>
> Here's the preview repo: https://github.com/vlsi/jmeter-git-cleanup-result
>
> There's consistency issue with branch and tag naming.
> For instance:
> rel-2_0_0
> rel-2_1
> doc-v2_3_1
> docs-2.4
> docs-5.1
>
> tags/v5_1
>
> Frankly speaking, I would prefer to name release branches as
> release-$VERSION, and name tags as v$VERSION.
> For instance: release-5.1 branch and v5.1 tag.
>
> Of course we can't just rename old tags (since people might rely on that
> naming), however we could create v5.1 kind of tags for each v5_1, and we
> can use v5.2, and so on later.
> What do you think?
I agree it would be better if there had be a proper naming convention
from the start.
However it is too late to fix discrepancies now.
Also it will be confusing to have duplicate tags just to fix the names.
I would ignore the earlier discrepancies but document and then stick
to the current convention going forward.
> "docs-" branch name is misleading, as it effectively used as a release
> branch for a specific version.
Again, IMO it's too late to change this now.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> The 5.2-SNAPSHOT builds will hang around unless manually deleted
It will be superseded by CI automatically as soon as the vote passes and
the version is incremented to 5.2-SNAPSHOT.
1) As far as I read the discussion, no-one really cares of the past tags,
so I'm fine with just leaving tag placement "as is".
2) I'm inclined to drop docs/ folder from the source repository. It should
better be placed to the separate site repository.
3) I'm inclined to drop "test-bin" and "testhead" tags. The sad thing with
"testhead" is that tag has its own "root commit" somehow. Those tags are
not important anyway.
Then docs-x.y branches are pretty-much harmless. The only annoying thing is
the number of the branches, however it is manageable.
Here's the preview repo: https://github.com/vlsi/jmeter-git-cleanup-result
There's consistency issue with branch and tag naming.
For instance:
rel-2_0_0
rel-2_1
doc-v2_3_1
docs-2.4
docs-5.1
tags/v5_1
Frankly speaking, I would prefer to name release branches as
release-$VERSION, and name tags as v$VERSION.
For instance: release-5.1 branch and v5.1 tag.
Of course we can't just rename old tags (since people might rely on that
naming), however we could create v5.1 kind of tags for each v5_1, and we
can use v5.2, and so on later.
What do you think?
"docs-" branch name is misleading, as it effectively used as a release
branch for a specific version.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Mon, 25 Feb 2019 at 16:33, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb> AFAICT there were no changes to tags once created.
> sebb> Have you any counter-examples?
>
> sebb, please explain this:
> http://svn.apache.org/viewvc/jmeter/tags/v2_8_RC2/doap_JMeter.rdf?r1=1394979&r2=1394978&pathrev=1394979
>
> I read that as a commit that modifies doap_JMeter.rdf file in a
> tags/v2_8_RC2 "branch".
Yes, that is a mistake. It should not have happened.
As already explained, it is precisely because it's not possible to
make tags truly immutable that the vote mails contain the tag version.
> Apparently tags are very mutable species in SVN.
Yes, as I already wrote:
<quote>
Unfortunately SVN does not allow tags to be marked read-only, so it
has to be done by convention.
This is the way it has always been for ASF projects I have worked on.
</quote>
> sebb>This is not acceptable: as explained previously, it causes problems
> sebb>for CI builds.
>
> Do you mean SVN somehow magically prevents that issue?
No, I mean that the trunk/master repo should not be updated to the new
snapshot version until the release vote has succeeded.
> I value your passion to the details, however please note that JMeter SVN
> trunk causes CI issues right now.
> Current build.xml says "5.1-SNAPSHOT", and we all know 5.1 has already been
> released.
Yes, that needs to be updated, it should have been done at the time of release.
However this is a minor issue.
It will be corrected in the snapshot repo as soon as the version is
updated to 5.2-SNAPSHOT.
By contrast, if the trunk is updated to 5.2-SNAPSHOT before the
release vote, and the release fails, CI builds won't be replaced when
the version is backdated to 5.1-SNAPSHOT.
The 5.2-SNAPSHOT builds will hang around unless manually deleted; this
is confusing because they are older than the ongoing 5.1-SNAPSHOT
builds.
That is why the version is changed in the tag only, and trunk is only
updated upon release.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb> AFAICT there were no changes to tags once created.
sebb> Have you any counter-examples?
sebb, please explain this:
http://svn.apache.org/viewvc/jmeter/tags/v2_8_RC2/doap_JMeter.rdf?r1=1394979&r2=1394978&pathrev=1394979
I read that as a commit that modifies doap_JMeter.rdf file in a
tags/v2_8_RC2 "branch".
Apparently tags are very mutable species in SVN.
sebb>This is not acceptable: as explained previously, it causes problems
sebb>for CI builds.
Do you mean SVN somehow magically prevents that issue?
I value your passion to the details, however please note that JMeter SVN
trunk causes CI issues right now.
Current build.xml says "5.1-SNAPSHOT", and we all know 5.1 has already been
released.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Sun, 24 Feb 2019 at 16:09, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb>AFAIK, JMeter has used SVN tags in the conventional manner
>
> I'm not sure committing non-trivial code changes to /tags/ is a conventional manner.
> Conventional use of /tags/ is placing a copy there.
Huh?
AFAICT there were no changes to tags once created.
Have you any counter-examples?
> sebb>It is to allow the docs for the current release to be corrected after
>
> What is the purpose of updating documentation for past releases?
Not sure what you mean.
The branch is created for the maintaining current release.
Of course at some point that becomes a previous release, but SVN
branches are cheap so there's no particular need to drop them.
And if any changes were made, it would be good to review these before
deletion to ensure that the trunk docs have been corrected if
necessary.
> What's the purpose of having doc-v2_3_3 branch?
Not sure what you are asking here.
> sebb> Same as above; so the published Javadocs agree with the latest release.
>
> Javadocs are much more convenient to read from Maven Central artifacts and/or from http://javadoc.io/doc/org.apache.jmeter/ApacheJMeter_java/5.1 .
> IDE can automatically download -javadocs jars and display it it accordingly.
A lot of projects have Javadocs on the website.
> I'm sure we don't really want to place autogenerated files like *.class, *.jar, *.tar.gz, and *javadoc* under source control.
The Javadocs are are only in SVN to put them on the website.
> sebb> In what way? It's very clear from the SVN tags.
>
> They are not more than a subfolder, so there might be changes that are missing in the "mainline".
> Here's an example of a code change in a "tag" folder:
>
> oups! Revert
> https://svn.apache.org/repos/asf/jmeter/tags/v2_8_RC2@1394979
>
> Then there's this commit 1342362:
> Tag for pre-release
> https://svn.apache.org/repos/asf/jmeter/tags/v2_7_RC2@1342362
> http://svn.apache.org/viewvc?view=revision&revision=1342362
>
> The problem with 1342362 is it did edit multiple files (not just the usual version in build.xml), and it is absolutely not clear if those change was left on that "tag" only.
AFAICT it did not *change* files (apart from build.xml); it copied
them from trunk.
I think you are misreading the commit details.
> The "problem" with SVN tags (at least with the way JMeter uses them) is the history never continues from a tag. It just keeps hanging as a side branch.
This is not a problem in the way JMeter uses tags.
It is how tags are supposed to be used in SVN.
Create once and never change them.
> At the end of the day, SVN does not distinguish between tag and branch, so one can silently put code changes into a tag.
Not silently, because there will be a commit message.
But yes, tags are not immutable - that is why vote mails include the revision.
Unfortunately SVN does not allow tags to be marked read-only, so it
has to be done by convention.
This is the way it has always been for ASF projects I have worked on.
So this is not a JMeter issue.
> In other words, I would prefer the following history:
Are your referring to SVN or Git here?
> 1. Initial commit
> 2. hack, the version is 1.0-SNAPSHOT
> 3. Set version to 1.0. Tag v1.0 points to this commit
> 4. Set version to 1.1-SNAPSHOT.
> 5. hack, the version is still 1.1-SNAPSHOT, <-- master branch points to here
> .. creating RC ...
> 6. Set version to 1.1. create tag v1.1_RC1. "master" still points to commit #5
It's not clear exactly what commits are being made above.
It looks as though master (do you mean trunk?) may be changed to the
new version in step 3 before the release vote completes.
This is not acceptable: as explained previously, it causes problems
for CI builds.
> If vote succeeds, then master branch is promoted to commit 6. In other words, master should point to exactly the same commit which was voted on.
I agree that the release tag should agree with the tag that was voted on.
This is done in JMeter by copying the RC tag to the GA tag.
Other projects may do this differently, e.g. I think Tomcat uses a tag
without an RC suffix.
If the vote fails, the version is bumped for the next vote, i.e. the
failed version number is not used for a release.
But the end result is the same: the SVN GA tag can be tied directly to
the release vote.
> At the end of the day, the primary goal of Apache is to release source artifacts. Binaries are for convenience only.
>
> sebb>In what way? It's very clear from the SVN tags
>
> For instance, can you tell which version was affected by commit 1378856?
> Which version (or RC) includes the commit?
>
> Reduce log level (duplicates message from JMeterThread)
> https://svn.apache.org/repos/asf/jmeter/trunk@1378856
>
> If tags are placed (like my script does) at the mainline branch (in other words, if tags point to commits of "trunk" branch), then it is trivial (see "follows" and "precedes" in the attached 1378856_vs_tags.png)
>
> sebb>It is important that the online docs agree with the current release.
>
> If you mean "we don't want to publish snapshot" features to the site while we want to fix site typos, then I think the approach there is to keep release branches.
> Then if we need to update the site, we put relevant updates to the release branch (to the relevant xdocs files), build the docs and publish it.
> It is effectively the same thing as if we would like to release 4.0.1 with a code change. We could fork a branch, put some changes, and release it.
>
> Nevertheless I would prefer linear histories rather than complicated merge mess that happens with current tags and docs branches.
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
sebb>AFAIK, JMeter has used SVN tags in the conventional manner
I'm not sure committing non-trivial code changes to /tags/ is a
conventional manner.
Conventional use of /tags/ is placing a copy there.
sebb>It is to allow the docs for the current release to be corrected after
What is the purpose of updating documentation for past releases?
What's the purpose of having doc-v2_3_3 branch?
sebb> Same as above; so the published Javadocs agree with the latest
release.
Javadocs are much more convenient to read from Maven Central artifacts
and/or from http://javadoc.io/doc/org.apache.jmeter/ApacheJMeter_java/5.1 .
IDE can automatically download -javadocs jars and display it it accordingly.
I'm sure we don't really want to place autogenerated files like *.class,
*.jar, *.tar.gz, and *javadoc* under source control.
sebb> In what way? It's very clear from the SVN tags.
They are not more than a subfolder, so there might be changes that are
missing in the "mainline".
Here's an example of a code change in a "tag" folder:
oups! Revert
https://svn.apache.org/repos/asf/jmeter/tags/v2_8_RC2@1394979
Then there's this commit 1342362:
Tag for pre-release
https://svn.apache.org/repos/asf/jmeter/tags/v2_7_RC2@1342362
http://svn.apache.org/viewvc?view=revision&revision=1342362
The problem with 1342362 is it did edit multiple files (not just the usual
version in build.xml), and it is absolutely not clear if those change was
left on that "tag" only.
The "problem" with SVN tags (at least with the way JMeter uses them) is the
history never continues from a tag. It just keeps hanging as a side branch.
At the end of the day, SVN does not distinguish between tag and branch, so
one can silently put code changes into a tag.
In other words, I would prefer the following history:
1. Initial commit
2. hack, the version is 1.0-SNAPSHOT
3. Set version to 1.0. Tag v1.0 points to this commit
4. Set version to 1.1-SNAPSHOT.
5. hack, the version is still 1.1-SNAPSHOT, <-- master branch points to
here
.. creating RC ...
6. Set version to 1.1. create tag v1.1_RC1. "master" still points to
commit #5
If vote succeeds, then master branch is promoted to commit 6. In other
words, master should point to exactly the same commit which was voted on.
At the end of the day, the primary goal of Apache is to release source
artifacts. Binaries are for convenience only.
sebb>In what way? It's very clear from the SVN tags
For instance, can you tell which version was affected by commit 1378856?
Which version (or RC) includes the commit?
Reduce log level (duplicates message from JMeterThread)
https://svn.apache.org/repos/asf/jmeter/trunk@1378856
If tags are placed (like my script does) at the mainline branch (in other
words, if tags point to commits of "trunk" branch), then it is trivial (see
"follows" and "precedes" in the attached 1378856_vs_tags.png)
sebb>It is important that the online docs agree with the current release.
If you mean "we don't want to publish snapshot" features to the site while
we want to fix site typos, then I think the approach there is to keep
release branches.
Then if we need to update the site, we put relevant updates to the release
branch (to the relevant xdocs files), build the docs and publish it.
It is effectively the same thing as if we would like to release 4.0.1 with
a code change. We could fork a branch, put some changes, and release it.
Nevertheless I would prefer linear histories rather than complicated merge
mess that happens with current tags and docs branches.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Sat, 23 Feb 2019 at 15:48, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> > > 3) Tags (e.g. version tags) are located at separate branches which
> > > complicates history browsing
> > Can you give an example of this? I don't get what you mean.
>
> Please find an attached gitk view of the current Git mirror.
>
> In case you are not familiar with output, commits grow from the bottom
> (just like regular trees do).
>
> It bothers me in multiple ways:
> 1) V5_1_RC1, v5_1_RC2, and v5_1 tags are placed OUTSIDE of the trunk
> history. In other words, if I browse "trunk" history alone, I don't
> see tags at all
AFAIK, JMeter has used SVN tags in the conventional manner, i.e. they
are located under tags/.
I am not aware of ASF projects that do this differently.
If the JMeter way of creating tags causes a problem with the history,
then I suspect there is a problem with the way the JMeter Git repo was
created.
> 2) It is quite obscure which repository state is represented by RC.
In what way? It's very clear from the SVN tags.
If this is not clear from the Git version of the repo then I think
something has gone awry with the conversion.
> 3) V4_0 tags seem to be a complete mess (see attached
> jmeter_v4_history.png). For instance, can you tell which commits are
> there between V4_0_RC2 and V4_0_RC4? Can you tell why V4_0_RC5 is not
> between V4_0_RC4 and V4_0_RC6?
>
> We don't have lots of tags, so we could even "migrate" that manually,
> and it could be faster than trying to make that automatic.
> What do you think?
>
> A bit of a side question: what is the purpose of having docs-x.y branches?
It is to allow the docs for the current release to be corrected after
trunk has moved on beyond the release.
It is important that the online docs agree with the current release.
> What is the purpose of placing generated javadocs to docs-x.y branch?
Same as above; so the published Javadocs agree with the latest release.
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
> > 3) Tags (e.g. version tags) are located at separate branches which
> > complicates history browsing
> Can you give an example of this? I don't get what you mean.
Please find an attached gitk view of the current Git mirror.
In case you are not familiar with output, commits grow from the bottom
(just like regular trees do).
It bothers me in multiple ways:
1) V5_1_RC1, v5_1_RC2, and v5_1 tags are placed OUTSIDE of the trunk
history. In other words, if I browse "trunk" history alone, I don't
see tags at all
2) It is quite obscure which repository state is represented by RC.
3) V4_0 tags seem to be a complete mess (see attached
jmeter_v4_history.png). For instance, can you tell which commits are
there between V4_0_RC2 and V4_0_RC4? Can you tell why V4_0_RC5 is not
between V4_0_RC4 and V4_0_RC6?
We don't have lots of tags, so we could even "migrate" that manually,
and it could be faster than trying to make that automatic.
What do you think?
A bit of a side question: what is the purpose of having docs-x.y branches?
What is the purpose of placing generated javadocs to docs-x.y branch?
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 23.02.19 um 14:57 schrieb Vladimir Sitnikov:
> No idea yet.
I believe this was meant for the process of generating the git repo?
>
> Any suggestions?
My naive idea was to start with what we have, but that would have the
drawbacks, you described earlier.
Felix
>
> Vladimir
>
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
No idea yet.
Any suggestions?
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 23.02.19 um 14:13 schrieb Vladimir Sitnikov:
> Felix> We already have a working git repo that could be used for syncing into
> Felix> gitbox. (Although we would miss some of the history rewriting that
> Felix> happened on svn)
>
> I don't like the existing Git mirror since it contains two offenders:
> 1) jar files. JMeter history included ant.jar, dependencies, etc at
> various locations.
> 2) generated *.html files
So you would like to drop the docs folder for the complete history?
> 3) Tags (e.g. version tags) are located at separate branches which
> complicates history browsing
Can you give an example of this? I don't get what you mean.
>
> I think it is worth trying to fix those.
How would you approach this?
a) Export the subversion, massage the exported files and reimport them
into subversion, convert that to git?
b) Use the git clone and rebase the hell out of it?
c) Something completely different
Felix
>
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Felix> We already have a working git repo that could be used for syncing into
Felix> gitbox. (Although we would miss some of the history rewriting that
Felix> happened on svn)
I don't like the existing Git mirror since it contains two offenders:
1) jar files. JMeter history included ant.jar, dependencies, etc at
various locations.
2) generated *.html files
3) Tags (e.g. version tags) are located at separate branches which
complicates history browsing
I think it is worth trying to fix those.
Vladimir
Re: Migrate SVN -> Git
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 21.02.19 um 10:38 schrieb sebb:
> On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov
> <si...@gmail.com> wrote:
>>> What's the level of complexity ?
>> It can be done by infra.
>> The formal vote for the migration should pass.
>>
>>
>> I don't think JMeter needs advanced SVN features (e.g. fine-grained
>> access
>> control, externals, locks, partial directory checkout, and so on)
>>
>> It even looks like modern SVN client can work with Git repositories (I
>> haven't used SVN for a while though)
>>
>> Here's how Apache Subversion migrated their code:
>> https://issues.apache.org/jira/browse/INFRA-7524
>>
>>> Are there any risks ?
>> None of my knowledge
> The risk is that Git has a completely different approach to source
> control.
> It needs a different mindset.
> In many cases there is no direct mapping of SVN commands to Git commands.
> There will be a steep learning curve.
>
> It also needs more local storage.
> (Yes, there are ways round this, but they can cause other issues)
>
> The main differences I have encountered are:
> - it does not support SVN variables such as $Revision:$ (does JMeter
> still use those?)
I don't think we use them (and if so, we should remove the usage).
> - EOL handling is different. This may be an issue as some JMeter file
> types need to have a specific EOL (LF or CRLF).
Wouldn't this have surfaced already? We get a lot of PR via github.
There was surely someone using windows, don't you think?
> - a commit message cannot be changed. This is both good (cannot
> corrupt history) and bad (cannot correct the log or add a CVE tag to a
> commit log)
Funny thing is, that we already lost some of those redacted messages in
our git repository, as there is no rewriting of history in git (as you
noted).
I think we shouldn't rewrite history. CVE relevant commits could be
tagged if necessary.
> - commit history can get very noisy if people don't resync with the
> origin before pushing changes
>
> That's not to say it should not be used.
I love it, when you show the weak points. That lets us think about them.
>
> Whilst conversion of an SVN repo is mostly automatic (*),
> conversion of developer habits and expectations is another matter, and
> the effort should not be underestimated.
>
> (*) some conversions have been known to fail to convert some parts of
> history
> Sorry, don't have links at present; I think this affected Attic
We already have a working git repo that could be used for syncing into
gitbox. (Although we would miss some of the history rewriting that
happened on svn)
Felix
>
>> Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
On Thu, Feb 21, 2019 at 11:30 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Philippe> Will this not work:
> Philippe>
> https://blog.subgit.com/line-endings-handling-in-svn-git-and-subgit/
>
> What do you mean by "not work"?
>
I meant , "I think this will work no ? "
>
> This works flawlessly:
> https://github.com/apache/calcite/blob/master/.gitattributes#L15-L21
> What it does it says "*.sh files must always be in LF" while "*.bat files
> must always be in CRLF".
> I'm sure it should be enough for JMeter.
>
> Philippe>How do other team proceed as it's a mandatory step of security
> remediation
> for CVE.
>
> I don't think there's a rule that mandates that "commit message must be
> updated even in case it did not include CVE number at the time of commit".
> Apparently, if we still want to add notes to Git history we can use regular
> Git tags or Git notes (see https://git-scm.com/docs/git-notes )
> However, I'm sure site changelog update is just enough.
>
> sebb> - commit history can get very noisy if people don't resync with the
> sebb> origin before pushing changes
>
> In fact, git push just fails. It does not create noisy history behind the
> scenes.
> Committers could just agree to avoid "merge commits", then the history is
> sequential.
>
> Philippe>I guess we would be using :
>
> I don't think we have resources to maintain multiple concurrent JMeter
> branches.
> Do you suggest to release back-patches like 3.2.4 even after releasing 5.2?
>
No.
Ok for the note.
>
> So I think we should just prefer coding in master. I really don't see a
> reason to have "develop" and/or "feature" branches.
>
> > Whilst conversion of an SVN repo is mostly automatic (*),
>
> Current JMeter SVN repository contains code and site at the same time.
> We probably want to avoid repository cluttering by incoming javadoc
> results.
> We could use Git migration to trim large objects from a repository tree
> (e.g. we could pretend that "adding of 60MiB tika-api.jar never happened"
> and exclude that from Git repository)
>
> Current Git mirror takes 280MiB, and main space consumers there are:
> 63968460 lib/tika-app-1.18.jar
> 3176148 lib/xalan_2_7_1.jar
> 3078601 lib/xalan.jar
> 2038489 lib/commons-math3-3.5.jar
> 1812019 lib/xerces.jar
> 1499244 lib/xerces.jar
> and the endless number of 4207248 docs/api/index-all.html and files like
> that.
>
> we do have a bunch of 453230 xdocs/usermanual/component_reference.xml, and
> it probably makes sense to split the file anyway.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe> Will this not work:
Philippe>
https://blog.subgit.com/line-endings-handling-in-svn-git-and-subgit/
What do you mean by "not work"?
This works flawlessly:
https://github.com/apache/calcite/blob/master/.gitattributes#L15-L21
What it does it says "*.sh files must always be in LF" while "*.bat files
must always be in CRLF".
I'm sure it should be enough for JMeter.
Philippe>How do other team proceed as it's a mandatory step of security
remediation
for CVE.
I don't think there's a rule that mandates that "commit message must be
updated even in case it did not include CVE number at the time of commit".
Apparently, if we still want to add notes to Git history we can use regular
Git tags or Git notes (see https://git-scm.com/docs/git-notes )
However, I'm sure site changelog update is just enough.
sebb> - commit history can get very noisy if people don't resync with the
sebb> origin before pushing changes
In fact, git push just fails. It does not create noisy history behind the
scenes.
Committers could just agree to avoid "merge commits", then the history is
sequential.
Philippe>I guess we would be using :
I don't think we have resources to maintain multiple concurrent JMeter
branches.
Do you suggest to release back-patches like 3.2.4 even after releasing 5.2?
So I think we should just prefer coding in master. I really don't see a
reason to have "develop" and/or "feature" branches.
> Whilst conversion of an SVN repo is mostly automatic (*),
Current JMeter SVN repository contains code and site at the same time.
We probably want to avoid repository cluttering by incoming javadoc results.
We could use Git migration to trim large objects from a repository tree
(e.g. we could pretend that "adding of 60MiB tika-api.jar never happened"
and exclude that from Git repository)
Current Git mirror takes 280MiB, and main space consumers there are:
63968460 lib/tika-app-1.18.jar
3176148 lib/xalan_2_7_1.jar
3078601 lib/xalan.jar
2038489 lib/commons-math3-3.5.jar
1812019 lib/xerces.jar
1499244 lib/xerces.jar
and the endless number of 4207248 docs/api/index-all.html and files like
that.
we do have a bunch of 453230 xdocs/usermanual/component_reference.xml, and
it probably makes sense to split the file anyway.
Vladimir
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Thu, 21 Feb 2019 at 09:59, Philippe Mouawad
<p....@ubik-ingenierie.com> wrote:
>
> On Thu, Feb 21, 2019 at 10:39 AM sebb <se...@gmail.com> wrote:
>
> > On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov
> > <si...@gmail.com> wrote:
> > >
> > > >What's the level of complexity ?
> > >
> > > It can be done by infra.
> > > The formal vote for the migration should pass.
> > >
> > >
> > > I don't think JMeter needs advanced SVN features (e.g. fine-grained
> > access
> > > control, externals, locks, partial directory checkout, and so on)
> > >
> > > It even looks like modern SVN client can work with Git repositories (I
> > > haven't used SVN for a while though)
> > >
> > > Here's how Apache Subversion migrated their code:
> > > https://issues.apache.org/jira/browse/INFRA-7524
> > >
> > > >Are there any risks ?
> > >
> > > None of my knowledge
> >
> > The risk is that Git has a completely different approach to source control.
> > It needs a different mindset.
> > In many cases there is no direct mapping of SVN commands to Git commands.
> > There will be a steep learning curve.
> >
>
> I agree git is more complex but it is also more popular now and provides
> powerful features.
> And I think that in the team we all know git (at least to be able to do
> what we currently do with svn).
>
>
> > It also needs more local storage.
> > (Yes, there are ways round this, but they can cause other issues)
> >
> > The main differences I have encountered are:
> > - it does not support SVN variables such as $Revision:$ (does JMeter
> > still use those?)
> >
> We do but we can drop that.
>
> > - EOL handling is different. This may be an issue as some JMeter file
> > types need to have a specific EOL (LF or CRLF).
> >
>
> Will this not work:
> https://blog.subgit.com/line-endings-handling-in-svn-git-and-subgit/
>
No idea - it has to be investigated.
> > - a commit message cannot be changed. This is both good (cannot
> > corrupt history) and bad (cannot correct the log or add a CVE tag to a
> > commit log)
> >
>
> How do other team proceed as it's a mandatory step of security remediation
> for CVE.
No idea - again someone has to investigate and update the documentation.
>
> > - commit history can get very noisy if people don't resync with the
> > origin before pushing changes
> >
>
> I guess we would be using :
>
> - master branch for live version (5.1 as of now)
> - develop for nightly
> - feature branch
Using different branches is tangential to the problem.
The issue is if several people are working on the same branch, commits
can get noisy if people don't resync frequently.
It's not a major problem, but it does clutter the commit mailing list
making it harder to find changes.
Just have a look at the infra list [1]
[1] https://lists.apache.org/thread.html/38c0fd78223e5b61fe5317264abe2f20022cf0102b99789dd33c08ab@%3Ccommits.infra.apache.org%3E
Sorry, needs auth to view
>
>
> > That's not to say it should not be used.
> >
> > Whilst conversion of an SVN repo is mostly automatic (*),
> > conversion of developer habits and expectations is another matter, and
> > the effort should not be underestimated.
> >
>
> I think we all use GIT today on a frequent basis, we already in the team
> interact with Github (we propose PRs).
> I see no blocker for migration.
> On the contrary, we would gain time merging PRs.
>
>
> >
> > (*) some conversions have been known to fail to convert some parts of
> > history
> > Sorry, don't have links at present; I think this affected Attic
> >
> > > Vladimir
> >
>
>
>
>
>
>
> <https://www.openstreetmap.org/#map=18/50.69454/3.16455>
RE: Migrate SVN -> Git
Posted by Paulo Maia Borges <pm...@temenos.com>.
Disclaimer - I'm not a direct contributor. But I have:
- transitioned from Visual-Source-Safe (Ugh!!!) to SVN;
- Mercurial to Git;
- TFS to Git;
And I have lead («led») 2 teams through Git adoption, one very successfully, one still undergoing with very little success.
This is what I want to say about that:
#1 - Welcome to the 21st century... This is exactly what Git was built for, with pull requests and what not.
#2 - SVN is becoming a dying art, it might become harder over time to get new people interested in interacting with SVN projects.
#3 - Most importantly, I have to support sebb's answer - such change is somewhat impactful on the developers, due to the habits that they've grown, the ways they are used to working in, etc. «Old habits die hard» is the reason my most recent adoption project is struggling to gain traction - it's easy'ish but not trivial to learn Git (though using it wrapped up around a tool like TortoiseGit helps tons) and sometimes people are quite resistant to change their ways. This clearly qualifies as a risk, as there's the potential for people to use it incorrectly if they lack knowledge and experience (doing git "rebase" comes to mind :D ).
Regards,
Paulo Augusto Maia Borges
WWVzLCBJJ20gZ2Vla3kuIEJ1dCBzbyBhcmUgeW91IQ==
The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use or disclosure of the contents of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of TEMENOS. We recommend that you check this e-mail and any attachments against viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus transmitted by this e-mail.
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
On Thu, Feb 21, 2019 at 10:39 AM sebb <se...@gmail.com> wrote:
> On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov
> <si...@gmail.com> wrote:
> >
> > >What's the level of complexity ?
> >
> > It can be done by infra.
> > The formal vote for the migration should pass.
> >
> >
> > I don't think JMeter needs advanced SVN features (e.g. fine-grained
> access
> > control, externals, locks, partial directory checkout, and so on)
> >
> > It even looks like modern SVN client can work with Git repositories (I
> > haven't used SVN for a while though)
> >
> > Here's how Apache Subversion migrated their code:
> > https://issues.apache.org/jira/browse/INFRA-7524
> >
> > >Are there any risks ?
> >
> > None of my knowledge
>
> The risk is that Git has a completely different approach to source control.
> It needs a different mindset.
> In many cases there is no direct mapping of SVN commands to Git commands.
> There will be a steep learning curve.
>
I agree git is more complex but it is also more popular now and provides
powerful features.
And I think that in the team we all know git (at least to be able to do
what we currently do with svn).
> It also needs more local storage.
> (Yes, there are ways round this, but they can cause other issues)
>
> The main differences I have encountered are:
> - it does not support SVN variables such as $Revision:$ (does JMeter
> still use those?)
>
We do but we can drop that.
> - EOL handling is different. This may be an issue as some JMeter file
> types need to have a specific EOL (LF or CRLF).
>
Will this not work:
https://blog.subgit.com/line-endings-handling-in-svn-git-and-subgit/
> - a commit message cannot be changed. This is both good (cannot
> corrupt history) and bad (cannot correct the log or add a CVE tag to a
> commit log)
>
How do other team proceed as it's a mandatory step of security remediation
for CVE.
> - commit history can get very noisy if people don't resync with the
> origin before pushing changes
>
I guess we would be using :
- master branch for live version (5.1 as of now)
- develop for nightly
- feature branch
> That's not to say it should not be used.
>
> Whilst conversion of an SVN repo is mostly automatic (*),
> conversion of developer habits and expectations is another matter, and
> the effort should not be underestimated.
>
I think we all use GIT today on a frequent basis, we already in the team
interact with Github (we propose PRs).
I see no blocker for migration.
On the contrary, we would gain time merging PRs.
>
> (*) some conversions have been known to fail to convert some parts of
> history
> Sorry, don't have links at present; I think this affected Attic
>
> > Vladimir
>
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>
Re: Migrate SVN -> Git
Posted by sebb <se...@gmail.com>.
On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >What's the level of complexity ?
>
> It can be done by infra.
> The formal vote for the migration should pass.
>
>
> I don't think JMeter needs advanced SVN features (e.g. fine-grained access
> control, externals, locks, partial directory checkout, and so on)
>
> It even looks like modern SVN client can work with Git repositories (I
> haven't used SVN for a while though)
>
> Here's how Apache Subversion migrated their code:
> https://issues.apache.org/jira/browse/INFRA-7524
>
> >Are there any risks ?
>
> None of my knowledge
The risk is that Git has a completely different approach to source control.
It needs a different mindset.
In many cases there is no direct mapping of SVN commands to Git commands.
There will be a steep learning curve.
It also needs more local storage.
(Yes, there are ways round this, but they can cause other issues)
The main differences I have encountered are:
- it does not support SVN variables such as $Revision:$ (does JMeter
still use those?)
- EOL handling is different. This may be an issue as some JMeter file
types need to have a specific EOL (LF or CRLF).
- a commit message cannot be changed. This is both good (cannot
corrupt history) and bad (cannot correct the log or add a CVE tag to a
commit log)
- commit history can get very noisy if people don't resync with the
origin before pushing changes
That's not to say it should not be used.
Whilst conversion of an SVN repo is mostly automatic (*),
conversion of developer habits and expectations is another matter, and
the effort should not be underestimated.
(*) some conversions have been known to fail to convert some parts of history
Sorry, don't have links at present; I think this affected Attic
> Vladimir
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
>What's the level of complexity ?
It can be done by infra.
The formal vote for the migration should pass.
I don't think JMeter needs advanced SVN features (e.g. fine-grained access
control, externals, locks, partial directory checkout, and so on)
It even looks like modern SVN client can work with Git repositories (I
haven't used SVN for a while though)
Here's how Apache Subversion migrated their code:
https://issues.apache.org/jira/browse/INFRA-7524
>Are there any risks ?
None of my knowledge
Vladimir
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
+1 for me but I wouldn't be the implementer
Few questions:
- What's the level of complexity ?
- Is it done by Infrastructure ?
- Are there any risks ?
Thanks
On Wed, Feb 20, 2019 at 10:33 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Hi,
>
> What do you think of migrating to Git as a primary VCS?
> I've seen recent migration of Apache Calcite to Apache Gitbox (
> https://gitbox.apache.org/ ), and it is kind of great.
> The site can be hosted via gitbox as well (one typically creates a separate
> git repository for the site like https://github.com/apache/calcite-site ).
>
> It enables write access for GitHub repositories (e.g. committers can edit
> PRs, edit issues, close, label them, etc).
>
> Can you please express your opinion on that?
> If you struggle what to say, you might find the below options useful:
>
> [ ] ++1: 'Wow! I like this! Let's do it!'
> [ ] +1: 'Let's do it!'
> [ ] +0.9: 'This is a cool idea and i like it'
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Milamber <mi...@apache.org>.
Hello,
I share your vision Graham.
Today, Git is the standard for open source project, and even if the
developper needs to change the mindset, it's would be benefict to help
developpers/contributors to produce more and more contributions.
Maven or Gradle would be too a good remplacement of Ant. with a new
mindset and new behaviors to help developer.
So +1 for me, to migrate to Git/gradle or maven.
I would like to help on the change on the release process (which is very
link with svn and ant)
Milamber
On 22/02/2019 14:06, Graham Russell wrote:
> +1 for moving to git.
>
> I think the biggest benefit to move to git is that it will make the
> merging of all the PRs we get on the github mirror easier ;)
> Which might then lead to more people more willing to do it and
> therefore lead to more contributions.
>
> Does anyone know the ratio of Github PRs to patches via BZ in the last
> few releases?
>
> Both SVN/Ant and git/Gradle "work", so it comes down to developer
> experience of using but also finding help and getting support.
>
> Graham
>
> On Thu, 21 Feb 2019 at 20:15, Philippe Mouawad
> <ph...@gmail.com> wrote:
>> Hi Vladimir,
>>
>> As initially discussed, I thought you would do at least one of the two, the
>> Gradle being prioritary IMO.
>> But it looks like you won't be able to in the end ?
>>
>> Volunteers are welcome in this case, although you looked like having
>> interesting experience in Gradle that would have been very useful.
>>
>> Bon courage for your talks and preparations.
>>
>> Regards
>>
>> On Thu, Feb 21, 2019 at 8:11 PM Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> wrote:
>>
>>> I've studied a couple of recent INFRA tickets, and it looks like creating
>>> Git repositories is handled via https://selfserve.apache.org/
>>>
>>> So Git->SVN migration boils down to creating an empty repository, pushing
>>> code there. Then we should ask Infra to make SVN read-only, and things like
>>> that.
>>>
>>> At this point I think it makes sense to just create a side Git repository
>>> (e.g. a throw-away on GitHub), migrate JMeter code from SVN there, apply
>>> Ant to Gradle converter, and then check how it turns out.
>>>
>>> I don't really see much sense in migrating to Gradle before Git conversion
>>> (there are VCS-specific build steps).
>>>
>>> I don't really see much benefit from migrating to Git in a hurry either.
>>> There are build/release tasks like "site update", and I think we might want
>>> to have separate Git repository to serve the site contents.
>>> At this point I don't know how JMeter site works, so I don't know it should
>>> be mapped to Git/Gradle.
>>>
>>> I think I could handle the conversion, however it would be great if someone
>>> volunteers.
>>> The thing is I prepare a talk for https://jpoint.ru/en/ , and I help to
>>> organize https://heisenbug-piter.ru/en/ this spring, so Git/Gradle is not
>>> my priority at the moment.
>>>
>>> Vladimir
>>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Graham Russell <gr...@gmail.com>.
+1 for moving to git.
I think the biggest benefit to move to git is that it will make the
merging of all the PRs we get on the github mirror easier ;)
Which might then lead to more people more willing to do it and
therefore lead to more contributions.
Does anyone know the ratio of Github PRs to patches via BZ in the last
few releases?
Both SVN/Ant and git/Gradle "work", so it comes down to developer
experience of using but also finding help and getting support.
Graham
On Thu, 21 Feb 2019 at 20:15, Philippe Mouawad
<ph...@gmail.com> wrote:
>
> Hi Vladimir,
>
> As initially discussed, I thought you would do at least one of the two, the
> Gradle being prioritary IMO.
> But it looks like you won't be able to in the end ?
>
> Volunteers are welcome in this case, although you looked like having
> interesting experience in Gradle that would have been very useful.
>
> Bon courage for your talks and preparations.
>
> Regards
>
> On Thu, Feb 21, 2019 at 8:11 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > I've studied a couple of recent INFRA tickets, and it looks like creating
> > Git repositories is handled via https://selfserve.apache.org/
> >
> > So Git->SVN migration boils down to creating an empty repository, pushing
> > code there. Then we should ask Infra to make SVN read-only, and things like
> > that.
> >
> > At this point I think it makes sense to just create a side Git repository
> > (e.g. a throw-away on GitHub), migrate JMeter code from SVN there, apply
> > Ant to Gradle converter, and then check how it turns out.
> >
> > I don't really see much sense in migrating to Gradle before Git conversion
> > (there are VCS-specific build steps).
> >
> > I don't really see much benefit from migrating to Git in a hurry either.
> > There are build/release tasks like "site update", and I think we might want
> > to have separate Git repository to serve the site contents.
> > At this point I don't know how JMeter site works, so I don't know it should
> > be mapped to Git/Gradle.
> >
> > I think I could handle the conversion, however it would be great if someone
> > volunteers.
> > The thing is I prepare a talk for https://jpoint.ru/en/ , and I help to
> > organize https://heisenbug-piter.ru/en/ this spring, so Git/Gradle is not
> > my priority at the moment.
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Vladimir,
As initially discussed, I thought you would do at least one of the two, the
Gradle being prioritary IMO.
But it looks like you won't be able to in the end ?
Volunteers are welcome in this case, although you looked like having
interesting experience in Gradle that would have been very useful.
Bon courage for your talks and preparations.
Regards
On Thu, Feb 21, 2019 at 8:11 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> I've studied a couple of recent INFRA tickets, and it looks like creating
> Git repositories is handled via https://selfserve.apache.org/
>
> So Git->SVN migration boils down to creating an empty repository, pushing
> code there. Then we should ask Infra to make SVN read-only, and things like
> that.
>
> At this point I think it makes sense to just create a side Git repository
> (e.g. a throw-away on GitHub), migrate JMeter code from SVN there, apply
> Ant to Gradle converter, and then check how it turns out.
>
> I don't really see much sense in migrating to Gradle before Git conversion
> (there are VCS-specific build steps).
>
> I don't really see much benefit from migrating to Git in a hurry either.
> There are build/release tasks like "site update", and I think we might want
> to have separate Git repository to serve the site contents.
> At this point I don't know how JMeter site works, so I don't know it should
> be mapped to Git/Gradle.
>
> I think I could handle the conversion, however it would be great if someone
> volunteers.
> The thing is I prepare a talk for https://jpoint.ru/en/ , and I help to
> organize https://heisenbug-piter.ru/en/ this spring, so Git/Gradle is not
> my priority at the moment.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Migrate SVN -> Git
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've studied a couple of recent INFRA tickets, and it looks like creating
Git repositories is handled via https://selfserve.apache.org/
So Git->SVN migration boils down to creating an empty repository, pushing
code there. Then we should ask Infra to make SVN read-only, and things like
that.
At this point I think it makes sense to just create a side Git repository
(e.g. a throw-away on GitHub), migrate JMeter code from SVN there, apply
Ant to Gradle converter, and then check how it turns out.
I don't really see much sense in migrating to Gradle before Git conversion
(there are VCS-specific build steps).
I don't really see much benefit from migrating to Git in a hurry either.
There are build/release tasks like "site update", and I think we might want
to have separate Git repository to serve the site contents.
At this point I don't know how JMeter site works, so I don't know it should
be mapped to Git/Gradle.
I think I could handle the conversion, however it would be great if someone
volunteers.
The thing is I prepare a talk for https://jpoint.ru/en/ , and I help to
organize https://heisenbug-piter.ru/en/ this spring, so Git/Gradle is not
my priority at the moment.
Vladimir
Re: Migrate SVN -> Git
Posted by Andrey Pokhilko <ap...@ya.ru>.
+1, I know from experience how much easier is to work & review with
github PRs, compared to SVN, bugzilla and patches
Andrey Pokhilko
21.02.2019 0:33, Vladimir Sitnikov пишет:
> Hi,
>
> What do you think of migrating to Git as a primary VCS?
> I've seen recent migration of Apache Calcite to Apache Gitbox (
> https://gitbox.apache.org/ ), and it is kind of great.
> The site can be hosted via gitbox as well (one typically creates a separate
> git repository for the site like https://github.com/apache/calcite-site ).
>
> It enables write access for GitHub repositories (e.g. committers can edit
> PRs, edit issues, close, label them, etc).
>
> Can you please express your opinion on that?
> If you struggle what to say, you might find the below options useful:
>
> [ ] ++1: 'Wow! I like this! Let's do it!'
> [ ] +1: 'Let's do it!'
> [ ] +0.9: 'This is a cool idea and i like it'
>
> Vladimir
>