Cvs versioning windows

At a convenient point in time commit your changes to the server and if necessry merge in other peoples changes too. CVSNT is designed from the very beginning to support Multi Site development across wide are networks, plus all CVS Suite Servers come with built in Unison Repository Rreplication to allow you to synchronise your servers as often as you like efficiently and safely.

March Hare Software also offer advanced repository replication solutions for our Multi Site Level 4 or 5 Professional Support customers. Working in a team means working on the same side. If you want to work co-operatively with others then you can configure CVSNT server to allow multiple computers and different people to access the file at the same time, or set it so that each file will be accessed exclusively by one user at a time.

You can even set up branches so that different people can work on a single file at different points in it's lifecycle, eg: release 1 needs an update at the same time as release 2 is being written. You need to checkout a copy of the module to get a version-control copy of the files you just imported.

For more information see the section Checking Out a Module. Checking out a module from the repository gives you a local copy of the directory hierarchy that makes up the module. In the dialog box that pops up, specify the name of the module that you want to check out this will be the same name that the group leader specified while importing the module to the repository and the local folder where you want to check out the module to.

Select the Globals tab and make sure that Checkout read-only is un-checked. Note 1: Make sure all further work you do, is done on the files in the folder you have checked out the module to.

Any previous project files on your machine are NOT under version-control. For more information see the section Editing a File. When you create new files that you want to include in the repository, you must tell CVS to handle the files.

If the directory containing the files is not under CVS control, you will have to add it before adding the files. If you want to add entire directory hierarchy, you should look at the section Starting a New Module.

Select the directory, file or files that you want to add. As the files are only marked for addition, you have to commit them to enter them in the repository. For more information see section Committing changes. This may be cumbersome, but it enables other developers to track who is currently editing given files see step 5 below. Select a file that you want to edit by clicking on it in the workspace. The icon next to the filename changes to reflect the fact that you can edit it now.

Open the file by double-clicking on it and save the necessary changes. The icon next to the file becomes red, to indicate that it is a dirty file. It is possible to ask CVS who is currently editing a file. The list of known editors of the file is displayed in the output window.

All changes you make in the file that you have checked out are only to your local copy. If you want to make those changes available to others who access that file in the repository, you need to commit your changes to the repository by checking it in. Select the directory, file or files that you want to commit. In the Commit Settings dialog box, enter a log message to describe what changes you made and press Ok.

If the commit was successful, you will see the following message in the output:. Checking in readme. Note 1: Before committing, you should do an update to make sure there are no conflicts.

For more information see section Updating files. There might be more than one person working on the same file. One of the developers will have to merge in the changes made by the other developers before committing the changes.

The process of getting changes from the server to your local copy is called updating. Select the directory, file or files that you want to update. A merge conflict will result if two developers modify the same portion of a file. It's up to the developer to resolve conflicts by hand. CVS will not let you commit a file that has unresolved merge conflicts in it.

For example, the following output is generated in the output window:. Merging differences between 1. C readme. Note: If a merge conflict occurs, you need to manually resolve the conflict before you can proceed to commit your changes.

For more information see the section Resolving Conflicts. Two developers can modify the same file at the same time. One of the developers will have to merge in the other developer's changes before committing the file. If you don't check in your changes frequently you will be merging a lot. It's best to communicate with your team members to make sure you don't step on each other's toes. Let's say that someone modified a file that you've been working on. Now you have to merge in the other developer's changes.

At the same time, someone edits file B , adding new calls to function X using the old arguments. Change control refers to a number of things. First of all it can mean bug-tracking , that is being able to keep a database of reported bugs and the status of each one Is it fixed?

In what release? Has the bug submitter agreed that it is fixed? For interfacing CVS to an external bug-tracking system, see the rcsinfo and verifymsg files see Administrative files. Another aspect of change control is keeping track of the fact that changes to several files were in fact changed together as one logical change.

If you check in several files in a single cvs commit operation, CVS then forgets that those files were checked in together, and the fact that they have the same log message is the only thing tying them together.

Another aspect of change control, in some systems, is the ability to keep track of the status of each change. Some changes have been written by a developer, others have been reviewed by a second developer, and so on. Generally, the way to do this with CVS is to generate a diff using cvs diff or diff and email it to someone who can then apply it using the patch utility.

This is very flexible, but depends on mechanisms outside CVS to make sure nothing falls through the cracks. It should be possible to enforce mandatory use of a test suite using the commitinfo file. Some systems provide ways to ensure that changes or releases go through various steps, with various approvals as needed.

Generally, one can accomplish this with CVS but it might be a little more work. Also consider whether features such as branches and tags can be used to perform tasks such as doing work in a development tree and then merging certain changes over to a stable tree only once they have been proven. Previous: What is CVS not? The first thing to understand is that CVS stores all files in a centralized repository see Repository ; this section assumes that a repository is set up.

Suppose you are working on a simple compiler. The source consists of a handful of C files and a Makefile. For this, you use the checkout command:. Normally, you should not modify or remove any of the files in it. You start your favorite editor, hack away at backend. See Multiple developers , for an explanation. When you have checked that the compiler is still compilable you decide to make a new version of backend. This will store your new backend. CVS starts an editor, to allow you to enter a log message.

When CVS starts the editor, it includes a list of files which are modified. For the CVS client, this list is based on comparing the modification time of the file against the modification time that the file had when it was last gotten or updated. The simplest way to handle this is simply not to worry about it—if you proceed with the commit CVS will detect that the contents are not modified and treat it as an unmodified file.

The next update will clue CVS in to the fact that the file is unmodified, and it will reset its stored timestamp so that the file will not show up in future editor sessions. Before you turn to other tasks you decide to remove your working copy of tc. One acceptable way to do that is of course. The release command checks that all your modifications have been committed. If history logging is enabled it also makes a note in the history file.

See history file. In the example above, the release command wrote a couple of lines of output. That is nothing to worry about: tc is the executable compiler, and it should not be stored in the repository. See cvsignore , for information about how to make that warning go away. See release output , for a complete explanation of all possible output from release. It means that the file driver. The release command always finishes by telling you how many modified files you have in your working copy of the sources, and then asks you for confirmation before deleting any files or making any note in the history file.

You decide to play it safe and answer n RET when release asks for confirmation. You do not remember modifying driver. This command runs diff to compare the version of driver. When you see the output you remember that you added a command line option that enabled the optimization pass.

You check it in, and release the module. The CVS repository stores a complete copy of all the files and directories which are under version control. Normally, you never access any of the files in the repository directly.

Instead, you use CVS commands to get your own copy of the files into a working directory , and then work on that copy. The repository then contains the changes which you have made, as well as recording exactly what you changed, when you changed it, and other such information. Note that the repository is not a subdirectory of the working directory, or vice versa; they should be in separate locations.

CVS can access a repository by a variety of means. It might be on the local computer, or it might be on a computer across the room or across the world. To distinguish various ways to access a repository, the repository name can start with an access method. For information on other access methods, see Remote repositories. The repository is split in two parts. The other directories contain the actual user-defined modules. There are several ways to tell CVS where to find the repository. You can name the repository on the command line explicitly, with the -d for "directory" option:.

Of course, for proper operation they should be two ways of referring to the same repository. In fact, the format has changed in the past, and is likely to change in the future.

Since in almost all cases one accesses the repository via CVS commands, such changes need not be disruptive. However, in some cases it may be necessary to understand how CVS stores data in the repository, for example you might need to track down CVS locks see Concurrency or you might need to deal with the file permissions appropriate for the repository.

The overall structure of the repository is a directory tree corresponding to the directories in the working directory. For example, supposing the repository is in. With the directories are history files for each file under version control.

The history files contain, among other things, enough information to recreate any revision of the file, a log of all commit messages and the user-name of the person who committed the revision. The history files are known as RCS files , because the first program to store files in that format was a version control system known as RCS. This file format has become very common—many systems other than CVS or RCS can at least import history files in this format.

The biggest difference is magic branches; for more information see Magic branch numbers. The directories inside the repository should be writable by the persons that have permission to modify the files in each directory. This normally means that you must create a UNIX group see group 5 consisting of the persons that are to edit the files in a project, and set up the repository so that it is that group that owns the directory. On some systems, you also need to set the set-group-ID-on-execution bit on the repository directories see chmod 1 so that newly-created files and directories get the group-ID of the parent directory rather than that of the current process.

Note that users must also have write access to check out files, because CVS needs to create lock files see Concurrency. CVS uses it to keep track of what tags are valid tag names it is sometimes updated when tags are used, as well as when they are created.

Each RCS file will be owned by the user who last checked it in. This has little significance; what really matters is who owns the directories. CVS tries to set up reasonable file permissions for new directories that are added inside the tree, but you must fix the permissions manually when a new directory should have different permissions than its parent directory.

Using pserver, you will generally need stricter permissions on the CVSROOT directory and directories above it in the tree; see Password authentication security. Some operating systems have features which allow a particular program to run with the ability to perform operations which the caller of the program could not. CVS was not written to use such features and therefore attempting to install CVS in this fashion will provide protection against only accidental lapses; anyone who is trying to circumvent the measure will be able to do so, and depending on how you have set it up may gain access to more than just CVS.

You may wish to instead consider pserver. It shares some of the same attributes, in terms of possibly providing a false sense of security or opening security holes wider than the ones you are trying to fix, so read the documentation on pserver security carefully if you are considering this option Password authentication security. Some file permission issues are specific to Windows operating systems Windows 95, Windows NT, and presumably future operating systems in this family.

If you are using local CVS and the repository is on a networked file system which is served by the Samba SMB server, some people have reported problems with permissions. If you find something out, please let us know as described in BUGS. It should not matter from a user point of view whether a file is in the attic; CVS keeps track of this and looks in the attic when it needs to.

But in case you want to know, the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state dead.

A dead state means that file has been removed, or never added, for that revision. For example, if you add a file on a branch, it will have a trunk revision in dead state, and a branch revision in a non- dead state. In the future additional files may be added to this directory, so implementations should silently ignore additional files. This behavior is implemented only by CVS 1. Other ent-type are reserved for future expansion. CVS 1. Note that the order of the lines is not significant; a program writing the fileattr file may rearrange them at its convenience.

Users with watches for this file. Users editing this file. Furthermore, joe is watching for edits and mary is watching for commits. Future files which are added should be checked out read-only. For an introduction to CVS locks focusing on user-visible behavior, see Concurrency. The following section is aimed at people who are writing tools which want to access a CVS repository without interfering with other tools accessing the same repository.

If you find yourself confused by concepts described here, like read lock , write lock , and deadlock , you might consult the literature on operating systems or databases.

Any file in the repository with a name starting with cvs. The directory cvs. That is, one must obtain this lock first before creating any of the other locks. To obtain a read lock, first create the cvs. This operation must be atomic which should be true for creating a directory under most operating systems.

If it fails because the directory already existed, wait for a while and try again. After obtaining the cvs. Then remove the cvs. Then proceed with reading the repository. When you are done, remove the cvs.

To obtain a write lock, first create the cvs. Then check that there are no files whose names start with cvs. If there are, remove cvs. If there are no readers, then create a file whose name is cvs.

Hang on to the cvs. Proceed with writing the repository. When you are done, first remove the cvs. Note that unlike the cvs. Note that each lock write lock or read lock only locks a single directory in the repository, including Attic and CVS but not including subdirectories which represent other directories under version control. To lock an entire tree, you need to lock each directory note that if you fail to obtain any lock you need, you must release the whole tree before waiting and trying again, to avoid deadlocks.

Note also that CVS expects write locks to control access to individual foo,v files. However, there are a few differences. For each administrative file, in addition to the RCS file, there is also a checked out copy of the file. For example, there is an RCS file loginfo,v and a file loginfo which contains the latest revision contained in loginfo,v. When you check in an administrative file, CVS should print.

If it does not, there is something wrong see BUGS. To add your own files to the files to be updated in this fashion, you can add them to the checkoutlist administrative file see checkoutlist. By default, the modules file behaves as described above. Therefore, by making appropriate edits to the CVS source code one can store the modules file in a database which implements the ndbm interface, such as Berkeley db or GDBM. If this option is in use, then the modules database will be stored in the files modules.

For information on the meaning of the various administrative files, see Administrative files. While we are discussing CVS internals which may become visible from time to time, we might as well talk about what CVS puts in the CVS directories in the working directories. But in some cases it may be useful to look at it, and other programs, such as the jCVS graphical user interface or the VC package for emacs, may need to look at it.

Such programs should follow the recommendations in this section if they hope to be able to work with other programs which use those files, including future versions of the programs just mentioned and the command-line CVS client. The CVS directory contains several files. Programs which are reading this directory should silently ignore files which are in the directory but which are not documented here, to allow for future expansion. The files are stored according to the text file convention for the system in question.

This means that working directories are not portable between systems with differing conventions for storing text files. This is intentional, on the theory that the files being managed by CVS probably will not be portable between such systems either. This file contains the current CVS root, as described in Specifying a repository. This file contains the directory within the repository which the current directory corresponds with. It can be either an absolute pathname or a relative pathname; CVS has had the ability to read either format since at least version 1.

The relative pathname is relative to the root, and is the more sensible approach, but the absolute pathname is quite common and implementations should accept either. For example, after the command. This file lists the files and directories in the working directory. The first character of each line indicates what sort of line it is. If the character is unrecognized, programs reading the file should silently skip that line, to allow for future expansion.

This is not a special case; to see whether a file is modified a program should take the timestamp of the file and simply do a string compare with timestamp. If there was a conflict, conflict can be set to the modification time of the file after the file has been written with conflict markers see Conflicts example. Thus if conflict is subsequently the same as the actual modification time of the file it means that the user has obviously not resolved the conflict.

Note that if timestamp contains a pair of timestamps separated by a space, rather than a single timestamp, you are dealing with a version of CVS earlier than CVS 1. This rule is so that files do not appear to be modified merely because the timezone changed for example, to or from summer time. Otherwise, the line looks like:. Programs which modify Entries files should preserve these fields. This file does not record any information beyond that in Entries , but it does provide a way to update the information without having to rewrite the entire Entries file, including the ability to preserve the information even if the program writing Entries and Entries.

Log abruptly aborts. Programs which are reading the Entries file should also check for Entries. If the latter exists, they should read Entries and then apply the changes mentioned in Entries. After applying the changes, the recommended practice is to rewrite Entries and then delete Entries.

The format of a line in Entries. Log is a single character command followed by a space followed by a line in the format specified for a line in Entries.

Log should be silently ignored for future expansion. If the second character of the line in Entries. Log is not a space, then it was written by an older version of CVS not documented here. Programs which are writing rather than reading can safely ignore Entries. Log if they so choose. This is a temporary file. Recommended usage is to write a new entries file to Entries.

Backup , and then to rename it atomically, where possible to Entries. The only relevant thing about this file is whether it exists or not. If it exists, then it means that only part of a directory was gotten and CVS will not create additional files in that directory. This file contains per-directory sticky tags or dates. This character is followed by the tag or date. Note that per-directory sticky tags or dates are used for things like applying to files which are newly added; they might not be the same as the sticky tags or dates on individual files.

For general information on sticky tags and dates, see Sticky tags. This file stores notifications for example, for edit or unedit which have not yet been sent to the server. Its format is not yet documented here. This file is to Notify as Entries. Backup is to Entries. That is, to write Notify , first write the new contents to Notify. If watches are in use, then an edit command stores the original copy of the file in the Base directory.

This allows the unedit command to operate even if it is unable to communicate with the server. The file lists the revision for each of the files in the Base directory. The format is:. This file is to Baserev as Entries. That is, to write Baserev , first write the new contents to Baserev. This file contains the template specified by the rcsinfo file see rcsinfo. See Administrative files , for a complete description. You can use CVS without any of these files, but some commands work better when at least the modules file is properly set up.

The most important of these files is the modules file. It defines all modules in the repository. This is a sample modules file. The modules file is line oriented. In its simplest form each line contains the name of the module, whitespace, and the directory where the module resides. The last four lines in the example above are examples of such lines. See modules , for a full explanation of all the available features.

You edit the administrative files in the same way that you would edit any other module. It is possible to commit an erroneous administrative file. You can often fix the error and check in a new revision, but sometimes a particularly bad error in the administrative file makes it impossible to commit new revisions. In some situations it is a good idea to have more than one repository, for instance if you have two development groups that work on separate projects without sharing any code.

The big advantage of having multiple repositories is that they can reside on different servers. With CVS version 1. With development versions of CVS , you can check out code from multiple servers into your working directory. CVS will recurse and handle all the details of making connections to as many server machines as necessary to perform the requested command.

Here is an example of how to set up a working directory:. This section describes how to set up a CVS repository for any sort of access method. After completing the setup described in this section, you should be able to access your CVS repository immediately via the local access method and several remote access methods.

For more information on setting up remote access to the repository you create in this section, please read the section on See Remote repositories. To set up a CVS repository, first choose the machine and disk on which you want to store the revision history of the source files. CPU and memory requirements are modest, so most machines should be adequate. For details see Server requirements. To estimate disk space requirements, if you are importing RCS files from another system, the size of those files is the approximate initial size of your repository, or if you are starting without any version history, a rule of thumb is to allow for the server approximately three times the size of the code to be under CVS for the repository you will eventually outgrow this, but not for a while.

The repository should be accessible directly or via a networked file system from all machines which want to use CVS in server or local mode; the client machines need not have any access to it other than via the CVS protocol. It is not possible to use CVS to read from a repository which one only has read access to; CVS needs to be able to create lock files see Concurrency.

To create a repository, run the cvs init command. It will set up an empty repository in the CVS root specified in the usual way see Repository. For example,. There is nothing particularly magical about the files in the repository; for the most part it is possible to back them up just like any other files. However, there are a few issues to consider. The first is that to be paranoid, one should either not use CVS during the backup, or have the backup program lock CVS while doing the backup.

To not use CVS , you might forbid logins to machines which can access the repository, turn off your CVS server, or similar mechanisms. The details would depend on your operating system and how you have CVS set up. To lock CVS , you would create cvs. See Concurrency , for more on CVS locks. Having said all this, if you just back up without any of these precautions, the results are unlikely to be particularly dire. Restoring from backup, the repository might be in an inconsistent state, but this would not be particularly hard to fix manually.

When you restore a repository from backup, assuming that changes in the repository were made after the time of the backup, working directories which were not affected by the failure may refer to revisions which no longer exist in the repository. Trying to run CVS in such directories will typically produce an error message. One way to get those changes back into the repository is as follows:. Just as backing up the files in the repository is pretty much like backing up any other files, if you need to move a repository from one place to another it is also pretty much like just moving any other collection of files.

The main thing to consider is that working directories point to the repository. The simplest way to deal with a moved repository is to just get a fresh working directory after the move. Your working copy of the sources can be on a different machine than the repository. You run CVS on a machine which can mount your working directory, known as the client , and tell it to communicate to a machine which can mount the repository, known as the server.

Generally, using a remote repository is just like using a local one, except that the format of the repository name is:. Specifying a password in the repository name is not recommended during checkout, since this will cause CVS to store a cleartext copy of the password in each created directory. The quick answer to what sort of machine is suitable as a server is that requirements are modest—a server with 32M of memory or even less can handle a fairly large source tree with a fair amount of activity.

The real answer, of course, is more complicated. Estimating the known areas of large memory consumption should be sufficient to estimate memory requirements. There are two such areas documented here; other memory consumption should be small by comparison if you find that is not the case, let us know, as described in BUGS , so we can update this documentation. The first area of big memory consumption is large checkouts, when using the CVS server.

The server consists of two processes for each client that it is serving. Memory consumption on the child process should remain fairly small. Memory consumption on the parent process, particularly if the network connection to the client is slow, can be expected to grow to slightly more than the size of the sources in a single directory, or two megabytes, whichever is larger.

Multiplying the size of each CVS server by the number of servers which you expect to have active at one time should give an idea of memory requirements for the server. For the most part, the memory consumed by the parent process probably can be swap space rather than physical memory. The second area of large memory consumption is diff , when checking in large files.

March Hare Software also offer advanced repository replication solutions for our Multi Site Level 4 or 5 Professional Support customers, contact a sales person today for more information.

CVSNT is designed to help you track changes to files - so we prefer to focus on it's ability to do just that. But for those who want to know, behind the scenes CVSNT has rename support, atomic checkouts, multi-threaded lock server, unique transaction identifiers session identifiers and commit identifiers , meta data, user definable keywords, efficient handling of binary files and the code is structured as a set of modules with well-defined interfaces.

Looking at some of our competitors web sites you'd think all that stuff was what was important. Yes CVSNT has all that - but what's important is getting your files versioned: accurately, securely, easily.

Stands Alone In an enterprise datacenter, or even a small business, every piece of software you run on your servers increases the number of security alerts you need to keep up to date with. This means that you can get your own copy of the source code. March Hare remains committed to the Open Source development model, and believe that it makes CVSNT a more robust, secure versioning system, as its core has been subjected to the crucible of peer review for decades.

Any problems found with this software can be immediately identified and fixed by March Hare Software and the Open Source community. Effective Configuration Management Implementing version control is the basis of a good configuration management system. Best Practice Don't confuse CVSNT's twenty year pedigree with tools that have been around forever but have not kept up to date with modern best practice.

Change Sets CVSNT Server incorporates support for user defined change sets bug numbers, job numbers so that each change you make to a file can be labelled with a meaningful change identification, whether it be your job number or the bug number.