On Thu, 21 Feb 2019 at 09:59, Philippe Mouawad <[email protected]> wrote: > > On Thu, Feb 21, 2019 at 10:39 AM sebb <[email protected]> wrote: > > > On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov > > <[email protected]> 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>
