Subversion Source Control General Information
|COMP 310 Java Resources Eclipse Resources
This page contains general information about the Subversion source control ("SVN"), independent of its usage via the Subclipse plug-in for Eclipse.
Go to the Subclipse page.
Fundamentally, source control consists of maintaining a centralized repository of all the code and other files associated with a software project. In addition, the repository holds the history of all the code and file changes made to a project over time and reconciling any differences between code saved by different developers at different times. Source control allows a developer to manage these files in a safe manner, especially when multiple developers are working on the same codebase. Whenever a developer "commits" their code, a new version is created, possibly requiring a merging or reconciliation of the differences between changes made by one developer vs those made by another.
In general, a source control system has a number of very useful features, of which these are the basics:
In addition, the source control system may contain or be supplemented by various ancillary functions such as
There are two main tCoypes or styles of source control: "commit-and-merge" and "check-in/check-out" or "lock". Each style has its advantages and disadvantages, and hence its dire-hard proponent and detractors:
Commit-and-merge: In this style, anyone can work on any file at any time, but when they commit the file back to the repository, the system attempts to merge its code with any other changes to the same file that have already been committed. These sorts of systems are easy to manage but can present some difficult merging issues. Subversion is a commit-and-merge style source control system. Subversion (SVN) is a commit-and-merge system.
Check-out/Check-in: In this style, only one person can work on any given file at a time. That person checks the file out to work on it, gaining an exclusive lock on that file that prevents other people from modifying it while it is checked out. When the person is done, they check the file back in, creating a new version and releasing it for modification by other people. The advantage of this style is that it avoids the potentially messy merge process. The down side is that it requires greater levels of synchronization between the user's local files and the repository plus excessively long check-out periods by other people can be frustrating. Microsoft's Team Foundation Server which Visual Studio, is a check-out/check-in style of source control.
There are many,
One of the more difficult tasks of source control involves keeping the local files system properly synchronized with the repository. In such, it is generally very dangerous to manipulate files that are under source control from outside of the source control system, e.g. renaming, moving or deleting files using Windows Explorer.
Always manage files under source control from inside the source control system, e.g. from within Eclipse+Subclipse.
The discussion here includes specifics to the SVN system and is thus not always generally applicable, especially to lock-style systems.
Check out -- To obtain a copy of the code saved in the repository for editing, typically the latest version.
Commit -- To request that a codebase or part of a codebase be added to the repository as a new version of the stored codebase.
Merge -- To combine and/or reconcile the differences between the latest version of the codebase in the repository and the code currently being committed.
Trunk -- The trunk is the main sequence of code commits that is created as the project progresses.
Branch -- A branch,of which there could be many, is a secondary sequence of commits which starts from a particular commit on the main trunk but then proceeds in a separate, parallel manner to the trunk, i.e. is "branching" off the trunk. Branches are commonly used to work on specific aspects of the project without disturbing or being disturbed by the changes being made in the main development trunk line. Branches can be "merged" back into the trunk to combine the net changes made in the branch with the changes made in the main trunk during that time.
Tag -- A tag is a snapshot of the latest version in SVN and are not part of a development line, that is, no more commits are performed to alter a tag once it has been made. Tags are used for archiving specific versions of the code. Typically, when a release of the codebase is authorized, a tag is made, which is the released version.
At any given moment, a developer is working on code based on a particular version saved in SVN. However, before that developer can commit his/her changes to SVN, another developer may have already committed their changes. The code the developer is commiting is thus not based on the latest version in SVN and thus may need to "merged" with it to create a new, self-consistent version.
Branches allow the development team to create parallel development paths, enabling progress on multiple fronts with minimized cross-interference. Tags allow a version to be archived as a static entity.
© 2020 by Stephen Wong