On Thu, Feb 21, 2019 at 11:30 AM Vladimir Sitnikov < [email protected]> 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.
