SVN (Subversion)

SVN (Subversion)

1. Introduction
2. Installation and Environment setup (Windows/Linux)
3. Basic SVN Concepts & Components (Version control system/Version Control Terminologies)
4. SVN Commands (checkout, commit, status, merge, info)
5. SVN for Eclipse
6. Import, check-in, check-out, resolve conflict with eclipse.

(1) Introduction

Apache Subversion which is often abbreviated as SVN is a software versioning and revision control system distributed under an open source license. Subversion was created by CollabNet Inc. in 2000, but now it is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users.

Subversion is one of many version control options available today. It's often abbreviated as SVN. Subversion is used for maintaining current and historical versions of projects. Subversion is an open-source centralized version control system. It's licensed under Apache. It's also referred to as a software version and re-versioning control system. SVN stands for Subversion. So, SVN and Subversion are the same. SVN is used to manage and track changes to code and assets across projects.

A SVN repository is a collection of files complete with a full history of changes. SVN is a centralized version control system. It's different from distributed systems, like Git. Centralized version control means that the version history is stored on a central server. When a developer wants to make changes to certain files, they pull files from that central server to their own computer. After the developer has made changes, they send the changed files back to the central server.

Here's how SVN works.?

SVN originally was designed as a command line interface. This means you would open your Terminal and type text commands.

For Subversion to work, the SVN setup needs two main elements:

• The server, which has all versions of all source files
• A local copy of the files, which is on your computer

The files on your computer are called working files. These are the files in which each user makes edits. Then, users commit their changes to the SVN server. Each time a user commits a change, SVN manages and records it by creating a new version. Like most version control options, users typically work with the most recent version. But if an older version is needed, you can revert to an earlier version.

(2) Installation and Environment setup

Installation in Windows and Linux(mint):

https://docs.oracle.com/middleware/1212/core/MAVEN/config_svn.htm#MAVEN8817

(3) Basic SVN Concepts & Components

Version control system

Version control systems are a category of software tools that helps in recording changes made to files by keeping a track of modifications done to the code.?

Benefits of the version control system:

1. Enhances the project development speed by providing efficient collaboration,
2. Leverages the productivity, expedites product delivery, and skills of the employees through better communication and assistance,
3. Reduce possibilities of errors and conflicts meanwhile project development through traceability to every small change,
4. Employees or contributors to the project can contribute from anywhere irrespective of the different geographical locations through this VCS,
5. For each different contributor to the project, a different working copy is maintained and not merged to the main file unless the working copy is validated. The most popular example is Git, Helix core, Microsoft TFS,
6. Helps in recovery in case of any disaster or contingent situation,
7. Informs us about Who, What, When, and Why changes have been made.

Use of Version Control System:?

A repository: It can be thought of as a database of changes. It contains all the edits and historical versions (snapshots) of the project.

Copy of Work (sometimes called checkout): It is the personal copy of all the files in a project. You can edit this copy, without affecting the work of others and you can finally commit your changes to a repository when you are done making your changes.

Types of Version Control Systems:?

Local Version Control Systems: It is one of the simplest forms and has a database that kept all the changes to files under revision control. RCS is one of the most common VCS tools. It keeps patch sets (differences between files) in a special format on disk. By adding up all the patches it can then re-create what any file looked like at any point in time.?

Centralized Version Control Systems: Centralized version control systems contain just one repository and each user gets their own working copy. You need to commit to reflecting your changes in the repository. It is possible for others to see your changes by updating.?

Two things are required to make your changes visible to others which are:?

• You commit
• They update

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst developers along with providing insight to a certain extent on what everyone else is doing on the project. It allows administrators to have fine-grained control over who can do what. It has some downsides as well which led to the development of DVS. The most obvious is the single point of failure that the centralized repository represents if it goes down during that period collaboration and saving versioned changes is not possible. What if the hard disk of the central database becomes corrupted, and proper backups haven’t been kept? You lose absolutely everything.?

Distributed Version Control Systems: Distributed version control systems contain multiple repositories. Each user has their own repository and working copy. Just committing your changes will not give others access to your changes. This is because commits will reflect those changes in your local repository and you need to push them in order to make them visible on the central repository. Similarly, When you update, you do not get other’s changes unless you have first pulled those changes into your repository.?

To make your changes visible to others, 4 things are required:?

• You commit
• You push
• They pull
• They update

The most popular distributed version control systems are Git, and Mercurial. They help us overcome the problem of a single point of failure.

Purpose of Version Control:?

• Multiple people can work simultaneously on a single project. Everyone works on and edits their own copy of the files and it is up to them when they wish to share the changes made by them with the rest of the team.
• It also enables one person to use multiple computers to work on a project, so it is valuable even if you are working by yourself.
• It integrates the work that is done simultaneously by different members of the team. In some rare case, when conflicting edits are made by two people to the same line of a file, then human assistance is requested by the version control system in deciding what should be done.
• Version control provides access to the historical versions of a project. This is insurance against computer crashes or data loss. If any mistake is made, you can easily roll back to a previous version. It is also possible to undo specific edits that too without losing the work done in the meanwhile. It can be easily known when, why, and by whom any part of a file was edited.

Version Control Terminologies:

Version control is a system that lets you manage changes to files and projects. It is considered by many to be the backbone of professional software development due to its daily use by developers. Thus, understanding what it is, how to use it, and common terminology associated with its use is fundamental in the success of any developer.?

Version control has several names and is also called source control or source control management. It's also occasionally referred to as “revision control,” although the term is rarely used. Instead, you will predominantly hear it called “source control” and “version control.” The three main components of version control systems include the following:

• A safety net for restoring saved work.
• Collaboration.
• Trying ideas before adding them to a project.

Terminologies:

Repository: A shared database with the complete revision history of all files under version control. It’s master storage to store multiple revisions of all the files

Workspace: Also known as working copy. It’s a set of files on your local machine that you have retrieved from the Version Control Repository at a specific time or revision.? You need to check out data from the central repository to your local workspace and then all the work needs to be done on a working copy and then publish to the central repository so that everyone else can see them.

Trunk: The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master). It’s a main body of development, originating from the start of the project until the project completes.

Branches: It’s a set of files that needs to be created at one particular time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other. Branches are also known as “lines of development”. Even when a project has no explicit branches, development is still considered to be happening on the “main branch”, also known as the “mainline” or “trunk” or “master“.

Tag: A tag or label snapshot in time, consistent across many files for a particular state of the project at a point in time. Tags are generally used to mark interesting snapshots of the project. A tag is usually made for each release, so that we can obtain, directly from the version control system, the exact set of files/revisions comprising that release.

Check-out: This action creates a copy of the particular revision of a file [often the latest] from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. You can also have the ability to just check out a single directory if you wish so.

Update/ Pull: Update your working copy with the latest either through the central repository or through the other team member’s local workspace in case of DVCS.

Commit/ Check-In:? To make a change to the project, or to store a change in the version control database in such a way that it can be incorporated into future releases of the project. This copies your working directory back into the repository as a new version.

Push: In CVCS, commits are automatically and unavoidably pushed up to a predetermined central repository, while in DVCS the developer chooses when and where to push commits. Often it is the project’s master repository, the one from which public releases are made, but not always.

Log Message: A brief message about changes made to a revision when you check it in. The log messages can be used as a summary of the progress of changes in a file.

Revision/Version: A committed change in the history of a file or set of files. This is the numerical reference supplied by the VCS to track the different editions it is holding of the file.

Conflict: The situation when two members are trying to commit changes that affect the same region of the same file. These must be resolved either manually or by using a Merge tool.

Merge: Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version.

(4) SVN Commands (checkout, commit, status, merge, info)

SVN Checkout Command:

The svn checkout command is used to create the working copy of the SVN project. The checkout operation is needed to be performed once after each change occurs in the directory structure. If the directory structure is changed, we may need to re-check it.?

This command will be executed as follows:

svn checkout “URL Path” ?

Or

svn co “URL Path”??

The URL path is the path for the files and repositories. If the PATH is omitted, the default name of the URL will be used as the destination. If multiple URLs are given, each will be checked in the subdirectory of PATH. In these paths, the name of the subdirectory is the base of the URL.

SVN Commit Command:

The svn command is used to save the changes made on the repository. Whenever we made changes to our working copy and want to reflect it on the SVN server. In such a case, we have to make a commit operation.

The commit command will be executed as follows:

svn commit -m "Commit message."??

The commit message is a message for the audience that we are making changes on the project.

SVN Status Command:

The svn status command displays the status of the working copy. It shows the status of whether the repository is updated, added/deleted, or the file is not under revision control and more.

This command will be executed as follows:

svn status “path”

SVN Merge Command:

It is used to apply two differences between two sources to a working path.

This command will be executed as follows:

svn merge SOURCE1[@N] SOURCE2[@M] [TARGET_PATH]??

The above command will merge the changes to the same destination.

SVN Info Command:

The svn info command provides a quick look at the working copy. It is accessible in the local working copy, and it does not communicate with the SVN server.

The info command will be executed as follows:

svn info

The above command will provide useful information about the repository.

(5) SVN for Eclipse

To use the SVN with Eclipse, we must have the following tools:

• SVN Server
• SVN Client
• JDK 1.8
• Eclipse IDE

To set up SVN in eclipse please follow the steps mentioned in this link.

https://www.javatpoint.com/svn-for-eclipse#

(6) Import, check-in, check-out, resolve conflict with eclipse.

https://youtu.be/7MB6T9ewidI