Using Source Control
This topic provides an overview of general source control concepts that are consistent among a number of source control systems, also known as automated change and software configuration management (SCM) systems.
- Note: Appmethod offers you version control functionality using several version control systems:
- The Subversion Integration in the IDE offers you built-in version-control functionality using the Subversion product.
- The Git Integration in the IDE offers you version-control functionality using the Git product.
- The Mercurial Integration in the IDE offers you version-control functionality using the Mercurial product.
Source Control Basics
Each source control system consists of one or more centralized repositories and a number of clients. A repository is a database that contains not only the actual data files, but also the structure of each project you define.
Most source control systems adhere to a concept of a logical project, within which files are stored, usually in one or more tree directory structures. A source control system project might contain one or many Appmethod projects in addition to other documents and artifacts. The system also enforces its own user authentication or, very often, takes advantage of the authentication provided by the underlying operating system. Doing so allows the source control system to maintain an audit trail or snapshot of updates to each file. These snapshots are typically referred to as diffs, for differences. By storing only the differences, the source control system can keep track of all changes with minimal storage requirements. When you want to see a complete copy of your file, the system performs a merge of the differences and presents you with a unified view. At the physical level, these differences are kept in separate files until you are ready to permanently merge your updates, at which time you can perform a commit action.
This approach allows you and other team members to work in parallel, simultaneously writing code for multiple shared projects, without the danger of an individual team member's code changes overwriting another's. Source control systems, in their most basic form, protect you from code conflicts and loss of early sources. Most source control systems give you the tools to manage code files with check-in and check-out capabilities, conflict reconciliation, and reporting capabilities. Most systems do not include logic conflict reconciliation or build management capabilities. For details about your particular source control system capabilities, refer to the appropriate product documentation provided by your source control system vendor.
Commonly, source control systems only allow you to compare and merge revisions for text-based files, such as source code files, HTML documents, and XML documents. Some source control systems allow you to include binary files, such as images or compiled code, in the projects you place under control. You cannot, however, compare or merge revisions of binary files. If you need to do more than store and retrieve specific revisions of of these types of files, you might consider creating a manual system for keeping tracking of the changes you make to binary files.
Source control systems store copies of source files and difference files in some form of database repository. In some systems, such as CVS or VSS, the repository is a logical structure that consists of a set of flat files and control files. In other systems, the repositories are instances of a particular database management system (DBMS) such as InterBase, Microsoft Access, MS SQL Server, IBM DB2, or Oracle.
Repositories are typically stored on a remote server, which allows multiple users to connect, check files in and out, and perform other management tasks simultaneously. You need to make sure that you establish connectivity not only with the server, but also with the database instance. Check with your network, system, and database administrators to make sure your machine is equipped with the necessary drivers and connectivity software, in addition to the client-side source control software.
Some source control systems allow you to create a local repository in which you can maintain a snapshot of your projects. Over time the local image of your projects differs from the remote repository. You can establish a regular policy for merging and committing changes from your local repository to the remote repository.
Generally, it is not safe to give each member of your team a separate repository on a shared project. If you are each working on completely separate projects and you want to keep each project under source control locally, you can use individual local repositories. You can also create these multiple repositories on a remote server, which provides centralized support, backup, and maintenance.
Working with Projects
Source control systems, like development environments, use the project concept to organize and track groups of related files. No matter which source control system you use, you create a project that maintains your file definitions and locations. You also create projects in Appmethod to organize the various assemblies and source code files for any given application. Appmethod stores the project parameters in a project file. You can store this file in your source control system project, in addition to the various code files you create. You might share your project file among all the developers on your team, or you might each maintain a separate project file.
Most source control systems consider development environment project files to be binary, whether they are actually binary files or not. As a consequence, when you check a project file into a source control system repository, the source control system overwrites older versions of the file with the newer one without attempting to merge changes. The same is true when you pull a project, or check out the project file; the newer version of the project file overwrites the older version without merging.
Working with Files
The file is the lowest-level object that you can manage in a source control system. Any code you want to maintain under source control must be contained in a file. Most source control systems store files in a logical tree structure. Some systems, such as CVS, actually use terms like branch, to refer to a directory level. You can create files in a Appmethod project and include them in your source control system, or you can pull existing files from the source control system. You can put an entire directory into the source control system, then you can check out individual files, multiple files, or entire subdirectory trees. Appmethod gives you control over your files at two levels - at the project level within Appmethod and in the source control system, through the Appmethod interface to the source control system.
Note: The History View provides revision information for your local source files. The History View can be used to track changes you make to files as you work on them in the Designer or the Code Editor.