Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

23.7.7.2 Local Version Control

When you make many changes to a file that comes from a remote repository, it can be convenient to have version control on your local machine as well. You can then record intermediate versions, revert to a previous state, etc., before you actually commit your changes to the remote server.

VC lets you do this by putting a file under a second, local version control system, so that the file is effectively registered in two systems at the same time. For the description here, we will assume that the remote system is CVS, and you use RCS locally, although the mechanism works with any combination of version control systems (back ends).

To make it work with other back ends, you must make sure that the “more local” back end comes before the “more remote” back end in the setting of vc-handled-backends (see Customizing VC). By default, this variable is set up so that you can use remote CVS and local RCS as described here.

To start using local RCS for a file that comes from a remote CVS server, you must register the file in RCS, by typing C-u C-x v v rcs <RET>. (In other words, use vc-next-action with a prefix argument, and specify RCS as the back end.)

You can do this at any time; it does not matter whether you have already modified the file with respect to the version in the CVS repository. If possible, VC tries to make the RCS master start with the unmodified repository version, then checks in any local changes as a new version. This works if you have not made any changes yet, or if the unmodified repository version exists locally as a version backup (see Version Backups). If the unmodified version is not available locally, the RCS master starts with the modified version; the only drawback to this is that you cannot compare your changes locally to what is stored in the repository.

The version number of the RCS master is derived from the current CVS version, starting a branch from it. For example, if the current CVS version is 1.23, the local RCS branch will be 1.23.1. Version 1.23 in the RCS master will be identical to version 1.23 under CVS; your first changes are checked in as 1.23.1.1. (If the unmodified file is not available locally, VC will check in the modified file twice, both as 1.23 and 1.23.1.1, to make the revision numbers consistent.)

If you do not use locking under CVS (the default), locking is also disabled for RCS, so that editing under RCS works exactly as under CVS.

When you are done with local editing, you can commit the final version back to the CVS repository by typing C-u C-x v v cvs <RET>. This initializes the log entry buffer (see Log Buffer) to contain all the log entries you have recorded in the RCS master; you can edit them as you wish, and then commit in CVS by typing C-c C-c. If the commit is successful, VC removes the RCS master, so that the file is once again registered under CVS only. (The RCS master is not actually deleted, just renamed by appending ‘~’ to the name, so that you can refer to it later if you wish.)

While using local RCS, you can pick up recent changes from the CVS repository into your local file, or commit some of your changes back to CVS, without terminating local RCS version control. To do this, switch to the CVS back end temporarily, with the C-x v b command:

C-x v b
Switch to another back end that the current file is registered under (vc-switch-backend).
C-u C-x v b backend <RET>
Switch to backend for the current file.

C-x v b does not change the buffer contents, or any files; it only changes VC's perspective on how to handle the file. Any subsequent VC commands for that file will operate on the back end that is currently selected.

If the current file is registered in more than one back end, typing C-x v b “cycles” through all of these back ends. With a prefix argument, it asks for the back end to use in the minibuffer.

Thus, if you are using local RCS, and you want to pick up some recent changes in the file from remote CVS, first visit the file, then type C-x v b to switch to CVS, and finally use C-x v m <RET> to merge the news (see Merging). You can then switch back to RCS by typing C-x v b again, and continue to edit locally.

But if you do this, the revision numbers in the RCS master no longer correspond to those of CVS. Technically, this is not a problem, but it can become difficult to keep track of what is in the CVS repository and what is not. So we suggest that you return from time to time to CVS-only operation, by committing your local changes back to the repository using C-u C-x v v cvs <RET>.


 
 
  Published under the terms of the GNU General Public License Design by Interspire