Newbie to SVN

[Vinay Salian]

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 !

[Bruce C]

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.

[Thorsten Schöning]

Guten Tag Vinay Salian via TortoiseSVN,
am Samstag, 24. Oktober 2020 um 11:22 schrieben Sie:

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

Yes and no. Yes, it will provide you tools to e.g. merge your concrete
bugfix from one version into another and tell you about conflicts. But
no, it will not do such things automatically and won't keep track of
where some fixes need to be applied or things like that.

Such things are not expected to be SVN's part, but you need a
Bugtracker like Bugzilla, JIRA, GitLab etc. additionally. Those
bugtrackers are keeping track of your different versions of the
software and you can ceate bugs against different affected versions.
By the pure fact of having open bugs you always know where you still
need to apply fixes or not, e.g. because of unsupported versions.

So be prepared to make yourself familiar with SCMs like SVN/GIT and
bugtrackers, modern software development uses both most likely.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail: Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow