4/28/2023 0 Comments Subversion softwareYes, there are all those complex guides out there which describe how Git is trivial once you understand that branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space. Of course SVN may be more familiar but that’s about the only reason, and I’ve found both Hg and Git very easy (and very fast) to learn. Would there be any specific reason to use Subversion those daysĪpart from tooling support in IDEs (which I don’t use) – not really, no. Someone mentioned tooling (for visual studio) as a reason to stick to SVN. Better support from CI tools such as Bamboo.Can continue development even without a network connection.No dedicated server required Actually, both can be used w/o a server.So I would strongly recommend that you choose a Distributed Version Control (such as Git) for your project. I have seen a lot of pro SVN comments, but all of them tend to be of the nature "SVN is not bad" rather than "SVN is better". But if you stick to an older version control (in a new setup) you will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration anyway. If the company is well established with a lot of source code in the existing version control system, moving to a new system is a big task, but if the company is small or starting up, moving to a new version control is very easy. I remember the same discussion when SVN was new and people were used to CVS, lots of arguments were given for not using SVN, but eventually SVN became the most popular version control system. It is here to stay for a very long time, it is better that we adapt to it sooner than later. Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.ĭistributed Version Control seems to be an eventuality. If you have the buffer to accommodate the learning process for each developer, you should move to a good distributed version control system. It requires substantial learning for each developer. "If you have a task that can be done on six hours, it is better to write a tool that does it in 20 minutes, even when creating the tool takes six hours?"ĭistributed Version control is a different beast to tackle. It's significantly faster now than it was a couple years ago, and at this point, there's really no good reason to look at HG or Git for your project unless you actually need the advanced features of distributed version control. For example, with SVN you can pull changes from the repository, or commit your local changes to it, with a single operation, whereas HG and Git require two or three steps to do the equivalent work.Īnd with the recent revisions, SVN has fixed a lot of the performance issues that made people prefer HG and Git. If you only have one central repository (which is all your company will need if they're still small enough to get by without source control so far), it's much simpler to use SVN to interact with it. SVN is much simpler to use than distributed version control, especially if you're not actually running a distributed project that needs distributed version control. It's is still in extremely wide use, and it's not going anywhere anytime soon.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |