Getting Started W ith CVS

An Oracle White Paper February 2005

Getting Started W ith CVS

Introduction...... 3 W HAT IS CVS...... 3 terminology...... 3 CVS Step by step...... 4 Downloading and Installing CVS...... 4 Creating a Repository...... 5 Creating a CVS Connection...... 5 Configuring the Repository...... 6 Importing a Module...... 7 Checking Out a Module...... 9 Adding Files...... 9 Updating Files (Common)...... 10 Editing Files...... 11 Deleting Files...... 11 Committing Files...... 12 Comparing Files...... 13 Merging Files...... 14 Renaming Files...... 14 View Revisions...... 14 Tagging Files...... 15 Updating Files (Special)...... 15 Retrieving Deleted Files...... 16 OTHER CVS CLIENTS...... 16 TortoiseCVS...... 16 W inCVS...... 17 SUBVERSION: THE BETTER CVS...... 18 More Information...... 18

White Paper Title Page 2 Getting Started W ith CVS

INTRODUCTION Are you in need of a tool that supports a structured way of sharing sources between developers? Or do you want to have the ability to exactly know what files you changed at some point in time, and perhaps be able to revert changes you have made? Than read on and find out how CVS can help you out and find out how CVS integrates with JDeveloper 10.1.2.

WHAT IS CVS CVS stands for Concurrent Versions System and is a so-called version control system. A version control system is used to keep several versions of a set of files, typically source code, in a repository. The files kept in the repository can be shared between developers, allowing them to see who is editing what files, what changes have been made by who, when and why that happened. You can revert to a previous version when necessary. The repository can reside anywhere on the network, which might be your local computer. So you can use a local, private repository when there is no need to share it with other developers.

TERMINOLOGY The CVS repository can contain one or more modules. A module basically is a folder structure, typically containing all (source code) files of one specific project. To create a module, the folder structure and the files in it need to be uploaded from the file system into the repository. This upload (that is the creation of a module) is called an import. From the moment a file has been uploaded into the repository, it is said it has been put “under version control”. Before you can work with a module locally, you need to retrieve it from the repository by doing a checkout. Unlike some other version control systems, checking out a module with CVS has nothing to do with locking or flagging files as being edited, as will be explained later.

White Paper Title Page 3 The software you use to import or checkout a module is called a CVS client. The CVS client can either be some stand-alone program or being integrated with your IDE, as is the case with JDeveloper. W hen checking out a module some extra files are created that are used by the CVS client, to determine what files are new and what files have been edited. Before you can upload a new file into the repository, you need to add it. Adding a file is like registering it for the module it belongs to. Once you finished your work, you can upload modified and new files (that have been added first) by doing a commit. In case of a modified file, this results in a new version or revision of that file. CVS will keep a history of all revisions, allowing you to revert to some previous version. You can retrieve other developers’ new or modified files from the repository by doing an update. If someone else has changed the file in the repository, CVS can automatically merge your changes during the update. W hile updating a file you can get a clean copy, which will undo any changes you have made. You can provide files with a tag, which is a label. Tagging is typically used to label a release of a module.

CVS STEP BY STEP The following will guide you through the options of CVS that you as a developer will use most often. In order to be able to practice most options on your own computer, the first step is to download CVS and create a repository.

Downloading and Installing CVS The core of CVS is the CVS engine, which is available for both Unix and W indows. Next to JDeveloper, this paper will discuss two popular CVS clients being TortoiseCVS and W inCVS, that both can act as a standalone CVS “engine” (the upcoming JDeveloper 10.1.3 will also be able to act as a standalone engine, but as this document is based on JDeveloper 10.1.2 that will not be discussed). In the remainder of this paper, TortoiseCVS or W inCVS is used to provide a standalone CVS engine, while JDeveloper is discussed as being the CVS client. At some point it is discussed how TortoiseCVS and W inCVS as a CVS client can add to JDeveloper. A few specifically useful features of TortoiseCVS and W inCVS are highlighted at the end of this paper. You can download TortoiseCVS from http://www.tortoisecvs.org and W inCVS from http://www.wincvs.org. For the remainder of this document it is assumed that you downloaded one of these clients and that you create a local, standalone repository. In case you need a shared repository CVSNT is recommended, which can be downloaded from http://www.cvsnt.com). After installing the CVS client, make sure the folder that contains cvs.exe is in your path (for example C:\Program Files\GNU\W inCVS 1.3\CVSNT or C:\Program Files\Tortoise).

White Paper Title Page 4 Creating a Repository In the remainder of the paper an example is used of a JDeveloper workspace called CVSTryouts that resides in the folder J:\demos\CVSTryouts. The workspace has three projects in it: McyAnalysis, McyModel and McyView. Suppose you want to store these projects in a repository called CVSTryouts. W e will then work to a situation as in the following figure, where the local project is at the left side and the repository at the right site.

The “remote” repository can reside anywhere on the network, including the same computer on which the local project folder structure resides. In this example does the local project reside on J-drive while the repository will reside on the D-drive. First you need to create a folder that will contain your CVS repository, for example D:\CVS. Open a command prompt box and check the path by executing the following command: cvs -version Keep the command prompt box open. You can now create the repository itself, by executing the following command in a command prompt window: cvs –d D:\CVS\CVSTryouts init The init command created a new folder D:\CVS\CVSTryouts, with a CVSROOT subfolder. This CVS root has been specified by the -d option and should refer to the absolute path of the repository to create. The CVSROOT folder is the “index” of the repository. The contents of the repository should not be modified by hand.

Creating a CVS Connection Before you can use CVS from JDeveloper, you need to configure JDeveloper to use CVS. You need to have the cvs.exe in your path first, as has been described in “Downloading and Installing CVS”. You can now configure JDeveloper to use CVS by going to Tools -> Preferences -> Extension M anager -> Version Control and choose CVS. The CVS client has now been integrated with JDeveloper.

White Paper Title Page 5 The next step is to create a CVS connection to your repository. You do this by opening the Connections Navigator, right-click on the CVS Server node and choose New CVS Connection. This opens the CVS Connection W izard. Create a new connection as follows: 1. Name: CVSTryouts You can call the connection anything you like, but for ease of recognition it is suggested you call it CVSTryouts, after the name of the repository. 2. Access Method: Local Because in this example you will work with a local repository. 3. Repository Path: D:\CVS\CVSTryouts The path refers to the folder containing the CVSROOT folder of the repository. 4. The Value of CVSROOT should now read “:local:D:\CVS\CVSTryouts”. Test the connection on the last tab.

Configuring the Repository Before you import your first module you need to configure the CVS repository to Before importing a module, configure the import binary files (for example images) as binary. If a binary file is imported as a CVS repository to import binary file type as binary, to prevent them from becoming text file (which is the default) it will get corrupted because CVS will convert line corrupted. endings and will try to do keyword substitution. To configure this, you need to edit the cvswrappers files of the CVSTryouts repository. As indicated earlier, it is good practice not to modify the repository itself (the files in the repository are write protected for this reason). Instead you checkout the CVSROOT folder from the repository as a module, modify the cvswrappers file and commit that file (remember that a module basically is nothing more than a folder structure?). In the next steps it is described how this can be achieved. The files of the CVSROOT module are going to be added to a new project, which should reside in a separate workspace (that is not in the CVSTryouts workspace). Therefore create the folder J:\demos\CVSTryoutsSettings and in that folder create a new JDeveloper workspace called CVSTryoutsSettings. Don’t let JDeveloper create a new project in it. You can now checkout the CVSROOT module by choosing Versioning -> Do not change the repository manually, to Check Out M odule. This will open the Check Out from CVS wizard. Fill this out prevent you corrupt it by mistake. If you need to change some CVS configuration as follows: file, check out the CVSROOT as a module, 1. Connection Name: CVSTryouts modify the specific configuration file locally and commit it to the repository. 2. Module Name: CVSROOT You can either enter this manually, or press the Get Module List button. W hen you press that button JDeveloper will automatically fill

White Paper Title Page 6 in CVSROOT, as currently that is the only module in the CVSTryouts repository. 3. Folder for Target: J:\demos\CVSTryoutsSettings\CVSROOT Instead of CVSROOT you can type in any valid folder name, but it is good practice to keep it the same as the folder in the repository. 4. Check Out into Target Folder: checked 5. Finish the wizard 6. Handle New Files: Create New Project from Files The repository itself should not become part of any existing project, so you choose to create a new project. 7. Create Project for CVS Checkout: fill in CVSROOT.jpr as project name and J:\demos\CVSTryoutsSettings\CVSROOT as folder name. 8. Press OK. Add the file J:\demos\CVSTryoutsSettings\CVSROOT\cvswrappers to the CVSROOT project and edit it. Suppose you expect to have *.gif, *.jpg, *.jpeg, *.jar and *.zip binary files in your project. You then add the following lines to the file (add any other binary type you want):

*.gif -k 'b' *.jpg -k 'b' *.jpeg -k 'b' *.jar -k 'b' *.zip -k 'b'

Save the file, right-click it in the system navigator and choose Commit. Fill in as Comments something like “configured binary files” and press OK. You can now safely import your first module!

Importing a Module Using JDeveloper, you can choose between importing individual projects or a workspace as a module. W hen you are on a project with multiple teams that work more or less independently on separate projects, you probably want to import each individual project as a module, so they can also be checked out or updated individually. Otherwise importing the complete workspace as a module is more appropriate. In this paper you will import the CVSTryouts workspace as a module. Right-click the CVSTryouts workspace and choose Import M odule. This opens the Import into CVS wizard. Fill out the wizard as follows, and let properties that are not discussed, keep their defaults:

White Paper Title Page 7 1. Connection Name: CVSTryouts Name the module after the workspace or project for ease of recognition. 2. Module Name: CVSTryouts Valid module names include any valid file name, excluding path information. For ease of recognition it is suggested you use the name of the workspace, or (when you import them individually) the project. 3. Folders for Sources: J:\demos\CVSTryouts\ Make sure this is the root of the folder that makes up your module. 4. Filter List: classes As there is no use in versioning class files you should exclude the root folder of the class tree. You can add here any other subfolder of the workspace or file type that you do not want to be put under version control. 5. Perform Module Checkout: checked As explained earlier, during a checkout the CVS client creates local files because it needs to determine what files have been modified and what files are new. As long as the module has not been checked out, you will not be able to synchronize files with the repository. 6. Finish the wizard

You have just imported your module! You can verify that by the fact that the workspace as well as the projects and files in it are indicated with a small coloured circle outlined in black as in the figure to the right. On your file system, you will see that in the J:\demos\CVSTryouts a CVS folder has been created, as well as in all other subdirectories. Also a J:\demos\CVSTryouts.backup folder has been created. W hat has happened, is that all files from the J:\demos\CVSTryouts folder have been uploaded, then the folder has been renamed to J:\demos\CVSTryouts.backup and after that the checkout has been performed to the newly created J:\demos\CVSTryouts folder. This new folder should be viewed as being a working copy (or “sandbox” as it is often called) of the original that now is in the repository. After you verified that all files have been uploaded correctly, you can delete the J:\demos\CVSTryouts.backup folder if you want. Before you do so you should especially check the binary files in your project (as they have been copied back there is no need to verify the files in the repository itself).

White Paper Title Page 8 Checking Out a Module To obtain a working copy of a module in the repository, you need to check out that module. As a matter of fact, you already did so with the CVSROOT module (see “Configuring the Repository”) and for the CVSTryouts module it has been done while importing it. But suppose you do not have a working copy of the CVSTryouts module (you can imitate this by deleting the CVSTryouts workspace from JDeveloper and delete the J:\demos\CVSTryouts folder).

Importing and checking out a module.

You check out the CVSTryouts module in JDeveloper by choosing from the menu Versioning -> Check Out M odule. This will open the Check Out from CVS wizard. Fill this out as follows: 1. Connection Name: CVSTryouts 2. Module Name: CVSTryouts You can either enter this manually, or press the Get Module List button and choose the CVSTryouts module from the dropdown list. 3. Folder for Target: J:\demos\CVSTryouts 4. Check Out into Target Folder: checked 5. Finish the wizard 6. Press OK. The CVSTryouts workspace has been added to JDeveloper with all projects and files in it. You can see which files are new and which files have been edited by in JDeveloper by going to Versioning -> View Uncommitted Files. W hen you do so right after the checkout, you will notice that the Uncommitted Files window lists many files. You can ignore this for the moment, close JDeveloper and start it again. The Uncommitted Files window will now be empty.

Adding Files The CVS repository will not know about new files unless you have added them first. Adding a file is like registering it for the module it belongs to.

White Paper Title Page 9 Suppose you have just created a new file called companyData.sql in the folder J:\demos\CVSTryouts\McyModel\scripts. You can see that this file is not yet under version control by the fact it is indicated with a cross as

in the figure to the right.

You can add the new file by right-clicking it and then choose from the menu Versioning > Add. On the Add to CVS window press OK. The file has now been added, but has not yet been committed. This is indicated with the black plus

symbol, as in the figure to the right.

Files to be added will not show in the Uncommitted Files window. The easiest way Always add a file as soon as it has been to add many files at once is by using either TortoiseCVS or W inCVS because they created to prevent that it is deleted during an update or not uploaded during a can scan a folder with its subfolders for files that have not yet been added (see also commit. “Other CVS Clients”). Currently JDeveloper has no such option so you need to select them explicitly. W hen you have added files using another CVS client you should refresh JDeveloper by choosing from the menu Versioning -> Refresh States.

Updating Files (Common) In case of team development you should do an update before you start working on any file to make sure that you have the most recent files in your working copy of the module. You can update a workspace by right-clicking it and then choose Update W orkspace Folder or update a project by choosing Update Project Folders. You can update an individual file by right-clicking it and then choose Update. In most cases updating a project is the most suitable option unless you plan to change files from multiple projects at the same time. By default Perform Clean Update is checked. W hen you leave this checked, files Always do an update before you start will be updated even if you modified them. New files that have been added will not editing files, to make sure you work with the most recent copies. It is preferred you be touched but new files that have not yet been added are deleted. In case of team do a clean update of the module before you development you normally want to do a clean update, for example to prevent start making changes. But first make sure compile errors that are the result of imports of source files that are outdated. you added any file that you want to keep, otherwise a clean update will delete these Another option you should check is Create New Folders. This will add any folder files. in the repository to your working copy if it does not yet exist locally. Otherwise CVS will not be able to download new files into that folder.

White Paper Title Page 10 An option you should also check is Prune Empty Folders. CVS will then delete When updating a module, also check any local folder that is empty after the update. This happens when files in that Create New Folders and Prune Empty Folders, to make that new folders are folder have been deleted in the repository, but you still have a copy of them. created and empty folders are deleted. Editing Files You can configure JDeveloper to check out files read-only (Tools -> Preferences - > CVS -> check Make New Files Read Only). But this is not by default, allowing you to edit any file. Especially when you work with a framework that is integrated with JDeveloper and uses configuration files (like ADF Business Components), you do not want to check out files read only. JDeveloper might need to update files you are not aware of. W hen these files are read-only JDeveloper will give an error message. Files that have been modified are indicated with an asterisk, like the businessobjects.xml file in the figure on the right. Mark that the package that contains the changed file, has also been marked as modified. W hen you work with other developers it is advised to agree upon some way of working that will minimize the need to merge changed files without frustrating the progress. You can mark a file as being edited or you can lock a file. The first option is the least intrusive, as it allows other developers to work on the same file. W hen you lock a file other developers cannot work with it. CVS has advanced capabilities of merging files, so in most cases locking files is not necessary. Marking and locking files is an advanced topic that is outside the scope of this paper.

Deleting Files You can delete a file by right-clicking it and then choose Versioning -> Remove. A removed file will automatically be deleted from the project. Initially JDeveloper will not show the removed file in the Uncommitted Files window. You need to choose Versioning -> Refresh States from the menu before a removed file is shown again. You should consider creating a tag for the module before deleting a significant amount of files at once. If you have done so you can restore them by updating the module using the tag name (see also “Updating Files (Special)”). Normally you won’t do so when deleting one or only a few files, to prevent you loose track by too many tags.

White Paper Title Page 11 CVS actually moves a removed file in the repository into a subdirectory called “Attic”, making it possible to restore it if necessary. After you have removed a file you will not be able to create a new file with the same (unless you manually modify the repository by modifying the Attic folder, which you should not do).

Committing Files At some point you need to upload modified or added files into the repository so that other people can retrieve them. You upload these files by committing them. At the same time files that have been removed will be deleted in the repository. You can get an overview of all files that are scheduled to be committed in the Uncommitted Files window. This window shows all files with the appropriate status as in the figure below.

You can commit individual selected files or all files at once by using respectively Always refresh the Uncommitted Files the “Commit” or “Commit All” buttons at the top of the Uncommitted Files window by choosing Refresh States from the Versioning menu and save all files W indow. You should refresh the window before pressing the Commit All button, before choosing Commit All. This is to by choosing from the menu Versioning -> Refresh States. Otherwise there is a prevent that deleted files and changed risk of not committing deleted files (see also “Deleting Files”). You should also index files are not committed. have saved all files before you press the Commit All button. This is because the fact that a file has been added or removed will change some index file like the JDeveloper project file. The changed index file should also be committed. Otherwise the project in the repository will be in an inconsistent state. W hen you press either one of the commit buttons the Commit to CVS window Always enter a statement that summarizes will appear in which you can add Comments about the changes. It is good practise what has been changed and why. This can be useful for developers whose work is to enter a clear statement that summarizes what has been changed and why. affected by the changes. In case of team development there is the risk that you have modified the same file as someone else has and that this someone else committed before you did. In CVS speak it is said that these two revisions “conflict” with each other. You cannot commit a file that has a conflict. See “Merging Files” to find out how to resolve conflicts. It is good practise to make small changes at a time. Before you commit a change, you do an update and test the change against the most recent project files, preferably using automated unit-tests. In case of team development the most important reason to keep the change small is to minimize interference with other changes and especially prevent the need to merge.

White Paper Title Page 12

Adding, committing and updating a file.

Comparing Files You can easily find out what the difference is between a modified file in your working copy and the one in the repository, by right-clicking it and then choose Compare W ith -> Previous Version. This will bring up the Compare W indow, like in the figure below.

As you can see changes are indicated by both a symbol in the margin and colours in the text (like blue with the ? symbol for a changed line and green with the + symbol for a new line). You can browse the differences using the buttons at the top of the Compare W indow. You can compare any two revisions of a file with each other by right-clicking the file and then choose Compare W ith -> Other Revision. This will bring up a window from which you can choose the right and the left version to compare with each other. You can compare two binaries files with each other if you want to, but normally this will not make much sense, as you are not able to interpret the differences.

White Paper Title Page 13 Merging Files In many cases CVS is able to merge conflicting revisions automatically when doing an update (see “Updating Files (Common)”). However, sometimes CVS fails to do so and sometimes you don’t want an automatic merge because that might corrupt the file, like is often the case with XML files. It is recommended you compare the local copy of the file with the revision in the repository (see “Comparing Files”) to verify if there is a conflict and if there is, decide how to resolve it. W hen CVS has automatically merged two files, it will have saved a copy of your original version. This copy has the same name as the original prefixed by “.#” and postfixed by the revision number, for example “.#myfile.java.1.4”. Overlapping modifications are marked in the merged file like in the following example:

<<<<<<< [file name] [your changes] ======[text as in the repository] >>>>>>> [revision]

You can resolve overlapping modifications by removing the marks and merge the changes manually. But sometimes the overlap is too complicated to be resolved this way. As an alternative you can move the local file out of the way (for example by renaming it) update the folder the file is in (which will download the revision from the repository) and merge the two versions manually.

Renaming Files Unfortunately there is no such thing as simply renaming a file that is under version Do not rename a file with JDeveloper (File -> control with CVS. W hen you want to rename a file, you should make a copy first, Rename). Currently JDeveloper will not remove the old file from the repository. As a give it the new name and add it to the project. Then you delete the file with the old result the old file will return when the folder is name (see “Deleting Files”) and add the file with the new name (see “Adding updated but not in the JDeveloper project. Files”). Explicitly remove the old file and add the new file instead. It is advised to separate committing the rename of a file from other changes. You can then add a comment which reads something like: “rename old_file -> new_file”. In this way renaming of files can be traced.

View Revisions You can view the revision history of an individual file by right-clicking it and then choose Versioning -> View History. This will also show the comments that have been entered when committing the revision to the repository (see also “Committing Files”). W inCVS has an option to create a graph of revisions of a file (see “W inCVS”).

White Paper Title Page 14 Tagging Files A tag is a symbolic name or label given to a specific set of files at a specific time. You typically tag an entire module, in order to be able to reconstruct the current state somewhere in the future. Tagging is therefore mostly done for every release of the module, just before starting to work on a new release. You can also tag an individual file or any subset of files of a module, but there is seldom a reason to do so. A tag name must start with a character and may only contain characters, numbers, underscores (“_”) and dashes (“-“). If you want to include a version number of the release in a tag it is advised to use dashes in the version number, for example “release_1-1-0”. In JDeveloper you can tag a module (workspace or project) by right-clicking it and choosing Versioning -> Tag W orkspace Folder or Versioning -> Tag Project Folder respectively. It is good practise to check Check for Changes while doing so, which results in an error being given when there is any modified or added file. In almost the same way you can remove an existing tag by checking Delete Tag. If you don’t know what tags exist, you can use TortoiseCVS or W inCVS find out (see “Other CVS Clients”).

Updating Files (Special) You can update a module (workspace or project) using a tag, which is typically done to retrieve a previous release. You retrieve a previous release of a module by right-clicking it and then choose Versioning -> Update W orkspace Folder or Versioning -> Update Project Folder respectively and check Perform Clean Update. Go to the Common Options tab and check Use Revision Number or Tag and fill in the tag name of the revision you want to retrieve. By checking Perform Clean Update you enforce that files that have been modified or added after the release and have not yet been committed are removed during the update. Otherwise the update might result in an inconsistent set of files. If you want to modify or add files for a previous tagged release, you must have created a branch for it before you can commit them. Branching is an advanced topic that is not dealt with in this paper. After you updated using a tag name, this tag name will have become “sticky” which means that with every following update only files that have been tagged with this name are retrieved. To get the most current version again you need to update the module by right-clicking it and then choose Versioning -> Update W orkspace Folder or Versioning -> Update Project Folder and then check Reset Sticky Options.

White Paper Title Page 15 Retrieving Deleted Files One way to retrieve deleted files is by doing a special update on the module using a tag. This will revert the entire module back to the state it was in when creating the tag, thereby undoing all changes that have been made since, including the removal of files. You can recover the deleted files, store them in a save place and update the module back to its current state (see “Updating Files (Special)”). You can then reuse the recovered files, but you cannot put them back in the same place using the same name. If you want to do that, you better use the other way, which is by restoring files individually. Before you can do so, you need to know the name of the file. W hen necessary you can take a look into the Attic folders of CVS (see also “Deleting Files”). After that you can restore the file using the command line version of CVS. First you add the file again and then you update it (JDeveloper, Tortoise, nor W inCVS have an option to add a non-existent file). Suppose you want to restore the file called ”myfile.java”. You can do this using the following commands:

cvs add myfile.java cvs update myfile.java cvs commit

CVS will respond with a message indicating that myfile.java has been resurrected. After that you need to add it to your JDeveloper project and refresh the CVS states.

OTHER CVS CLIENTS

TortoiseCVS TortoiseCVS is a one of the most popular CVS clients and integrates with W indow Explorer. You can execute the most often used CVS commands by right- clicking files or folders and choose the appropriate command from the context-sensitive menu, as shown in the figure to the right.

Very handy is the CVS Add Contents option, which can be used to add all new files in an entire folder tree at once (remember that with JDeveloper you need to add files individually). TortoiseCVS uses colours and icons to indicate the status of files. Files that are in sync with the repository are green, files that need to be committed red.

White Paper Title Page 16 W hen committing files, TortoiseCVS gives a clear overview of what it is about to commit, separating modified, added and removed files in three different columns, as in the following figure. You can deselect files you do not yet want to commit.

Do not forget to refresh the CVS states of files in JDeveloper whenever you changed them with TortoiseCVS. W hen you forgot what tags have been created you can fetch a list with all existing tags using the Tag option. TortoiseCVS is open source software and can be downloaded from http://www.tortoisecvs.org.

WinCVS Another very popular CVS client is W inCVS. W inCVS can also be used for more advanced CVS options, like creating a new repository. Very handy with W inCVS is that you can apply several standard views on a folder tree, to see what files have not yet been added or committed to the repository. You can thereby restrict the view to a specific folder or include all subfolders in it, as has been done in the following figure.

White Paper Title Page 17 You can sort all files by name, extension, folder and so on. You can also filter files on these properties, using wildcards. W inCVS can create a graph of all revisions of a file, including branches and tags. W hen you click on one of the revisions, you can see the comments that have been entered. W inCVS is open source software and can download W inCVS from http://www.wincvs.org/.

SUBVERSION: THE BETTER CVS At this point is CVS the de facto standard Source Code Management (SCM) tool on J2EE development projects, but will likely lose this position to Subversion. The goal of the Subversion project is “to build a compelling replacement for CVS in the open source community”. Subversion implements all of the functionality of CVS but without it’s design flaws. W hat makes Subversion therefore “The Better CVS” consists (among other things) of the following: • Atomic commit W hen you com m it two or m ore files with CVS and one of them has a conflict, the other file will be uploaded anyway. As a result the repository m ight be in an inconsistent state until you have resolved the conflict. Subversion im plem ents an atom ic com m it, m eaning that all files are uploaded without any conflict, or the com m it is entirely rolled back. • File renaming Unlike CVS does Subversion support file renam ing. • Storing binary files At the core does CVS use Revision Control System (RCS) to m anage m ultiple versions of files. In this paper we will suffice to say that this causes the “troubles” with the handling of binary files. Subversion has a different approach, as it will never do keyword or line-ending translations, unless explicitly instructed to do so. So unless you asked for it yourself, are binary files never corrupted by Subversion. There are plans to integrate subversion into JDeveloper, but no timescale has been set yet.

MORE INFORMATION You can find more information about the usage of CVS in the online help of JDeveloper, on the sites of CVSNT (http://www.cvsnt.com), TortoiseCVS (http://www.tortoisecvs.org) and W inCVS (http://www.wincvs.org). Another excellent reference for daily use of CVS can be found at http://ikon.as/wincvs- howto.

White Paper Title Page 18 More information about Subversion can be found at http://subversion.tigris.org. A TortoiseSVN client can be found at http://tortoisesvn.tigris.org. Other papers in the Getting Started W ith series are: Getting Started W ith: Unit-Testing, December 2004

White Paper Title Page 19 White Paper Title February 2005 Author: Jan Kettenis

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com

Copyright © 2005, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.