TortoiseSVN is stable and mature, so its development status is slow :-) But I mostly agree with Mark, using SVN is better than nothing after all. And because it's mature, it's unlikely that you find a bug that is critical for your everyday use...
Justin MASSIOT | Zentek On Thu, 28 Oct 2021 at 15:43, Mark Phippard <markp...@gmail.com> wrote: > On Thu, Oct 28, 2021 at 9:26 AM Luke Mauldin <lukemaul...@icloud.com> > wrote: > > > > Is the SVN repository still in use or was it transitioned to something > else? > > The primary users of this SVN repo will be engineers who are not > software developers so I think the less complex nature of SVN compared to > Git could be a definite advantage. However, I am concerned about the > long-term viability of the SVN project because I would like the repo to > still be usable by in 5-8 years. Just looking at the development mailing > lists, it looks like almost all development has stopped on Subversion which > is concerning to me. > > IMO, this should not be a big concern. Subversion development is slow > because the project is mature and stable. But for example, there was > some recent discussion and activity about making even more > improvements to handling of large binary files (your use case): > > https://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3c874kcf6xin....@red-bean.com%3e > I think this is an example of the type of improvement that will come > to this project in the coming years, but there are only so many of > these refinements left to make. I do not think any of the really big > problems, like how renames are handled, are likely ever to be solved. > > Ultimately what is the alternative? Not use version control at all? If > some better alternative emerges in the next 5-8 years it will almost > certainly provide a migration path for SVN repositories. You are > probably going to want to use a GUI client like TortoiseSVN. I have > not followed that recently but it is usually pretty active and there > is always room to make significant improvements in GUI clients that do > not require any changes in the core SVN API as most of them are just > about optimizing workflows. > > Mark >
