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