On Thu, Feb 21, 2019 at 10:39 AM sebb <seb...@gmail.com> wrote: > On Thu, 21 Feb 2019 at 05:12, Vladimir Sitnikov > <sitnikov.vladi...@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>
