The other option for me at the moment is to use Git and LFS which is somewhat similar but not ideal. You mention renames as an example of a problem that are unlikely to ever be resolved. Can you please elaborate on the issue? My understanding is that especially the newer versions of SVN potentially do a better job of tracking renames than Git because SVN actually tracks more file level information whereas Git only tracks the contents of files. Many times I have renamed a file in Git and then also changed a couple of lines of text and Git sees it as a delete/add and not a rename. I know that there are various options you can set in Git to allow 90% of text similarity to be tracked as a rename but its just a pain and not intuitive at all.
Luke > On Oct 28, 2021, at 8:43 AM, 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
