That's a rather big question. The good news is that you are correct that a version control tool will help you manage the changes to your code. You are also correct that Subersion is a version control tool. You are also correct that users in this TortoiseSVN user group have needed to address similar issues to yours.
Subversion is a specific version control tool and TortoiseSVN is a particular client application of that tool. (As you know, VisualSVN is another Subversion client application.) The questions here are mainly about specific issues using the particular TortoiseSVN client application. Your question relates to how to use the overall Subversion tool and most of the answer would be likely to relate to many other version control tools - not just Subversion (e.g. git). All users of TortoiseSVN are users of Subversion. However, not all users of Subversion use TortoiseSVN. Consequently, while there are many users here that need to solve similar issues, it may be helpful to consider seeking help in more general Subversion or version control user groups. As with any tool, there are many ways to use the tool. Exactly how you use the tool will depend on your specific needs. However, there are conventions of each tool that you'll probably want to adopt. You have two choices: - Invest the time and effort to learn the tool and then adapt that knowledge to use it for the specific needs of you and your team. - Find someone with the experience of the tool to work with you to understand your needs and help you best use the tool. That is, you are probably going to have to invest significant time or money to solve your problem. All that said, there are some things you need to consider. - Is Subversion the version control tool you want to use? There are alternatives (e.g. git) with pros and cons to each. - If you decide to use Subversion and work with a team, you will need a Subversion server. There are many ways to do this but the whole team will need to have network access to the system running the server. This might be across a LAN or the internet. Again, lots of choices. You'll then need to install and configure the Subversion server software. - You're going to need to decide how to structure things. For the system you've described, a single repository is probably the right choice. More complex systems might have multiple repositories. You probably need to think about any other projects you might want to put under version control and how those projects inter-relate to this project. - You'll then need to decide how to structure the repository. Most Subversion repositories have the basic top-level directories named *trunk*, *branches* and *tags*. It's going to take a little time to figure how best to use these for your project. - Having confirmed the repository structure, you'll then need to agree with the team how the structure will be used so that everyone's doing things the same way. For example, you might agree to have fixes made in the code for the next version (typically "trunk") and then merged across to v1.x, v2.x, v3.x, etc. Alternatively, you might decide to make the changes to v1.x and then merge them to v2.x, v3.x and then the next version (i.e. trunk). - Finally, you'll have to decide how you're going to move your existing code into the repository. How you go about this will depend on many of the previous choices. So, lots to do and most of it specific to the needs of you and your team. A very good Subversion reference is at http://svnbook.red-bean.com/. It also has a lot of good background information that might help you make your choices. Personally, I also used a book titled *"Pragmatic Version Control Using Subversion"*, although I think it's out of print as git tends to be more popular nowadays and there's a variant of the book for that. So, it's a big question with no simple answers. Hopefully this might give you some pointers. Unfortunately, I'm not in a position to help you more than this. Perhaps others will be able to contribute but it's probably up to you. On Saturday, 24 October 2020 at 10:22:18 UTC+1 [email protected] wrote: > Need some help here. > > We didnt have a specific IT department to manage the devleopment code for > Dot Net MVC application in our office . > > When the developement t with basic functionalities completed a year back > we labelled the software as v1 and froze it. We added a new folder v2 and > started adding features and fixing bugs which were encountered in V1. in > V1 nd V2 respectively.Now adding more features versions we have v3 and v4 > . Now it was becoming difficult manage all the bug fixes and versioning > .So somebody suggested we use Visual SVN and tortoise svn and now we want > to make a structure in SVN to handle all bugs in all versions . So if > we fix a bug in v4 and want it to be fixed in v1 too can svn handle this. > > Pardon me for asking such a newbie question but didnt find any litreture > on how to handle this in any documentation. > > Thanks in advance ! > -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/5af0186c-6d26-424e-8272-c1e5e2d78c10n%40googlegroups.com.
