## 2. The MacCVS Client

## 2.1 Introduction

The first port on Macintosh was made by Mike Ladwig using CodeWarrior 9, GUSI 1.7.2 and cvs 1.84. It allowed to use MacCVS as a console program or as a MacPerl command.

A second port was made by Matthias Neeracher. He implemented cvs as a MPW tool and used the cvs 1.9 distribution, dmake and CodeWarrior 9. This version works nicely but was never included into the official release of cvs.

Both use the excellent Matthias Neeracher's GUSI Library (for Grand Unified Sockets Library) which allows to port easily Unix code on Macintosh.

Despite of this ports, the cvs implementation for Macintosh is still experimental and only the client side is available.

This current port uses CodeWarrior Pro 3, the MSL library, cvs 1.10, GUSI 1.8.4, Waste 1.3, TCL 8.1 and optionnaly the KClient library (Kerberos authentication, a contribution of Miro Jurisic)

## 2.2 What is inside

This is my second tentative to port CVS for Macintosh.

The first time I used the port of Mike Ladwig and added a little UI to remember the CVSROOT and provide menu access.

Now using the Matthias Neeracher port, I've added again a little UI and also enhanced or added some capabilities to the MacCVS client to :

- deal with Macintosh files with a resource fork (using a HQX encoding or a MacBinary encoding).
- be scriptable by Apple Events.
- allow to import initial modules directly from the macintosh (see the problems relative to the import command).
- control when adding files : that's because many user make mistakes when adding files and forget to add "as binary" when the file is binary.
- use Internet Config to restore Mac signatures.
- provide a work around for files which auto-modify each time you open it (such as CW Pro 2 projects) : this behaviour is not compatible with CVS which checks for the modification date on your disk. We refer to this kind of files as dirty files
- rewrite the architecture of MacCVS so it uses cvs as a shared library (this has several advantages I discuss in Hacking CVS).

For more informations, look at the Hacking CVS section.

## 2.3 Binary and Text files

For the macintosh cvs client :

- a plain binary file is a file with a signature different of "TEXT" (for example a Word document .doc) and no resource fork.
- a mac binary file is a file with a signature different of "TEXT" and a resource fork (for example a ResEdit file and most of the mac files).
- a text file is a file with a signature of "TEXT".

MacCVS now supply some controls when adding files : that's because many user make mistakes when adding files and forget to add "as binary" when the file is binary. It will warn you if you are about to make a mistake.

Important : You can force a binary file to be handled as plain binary when you add or import files : that's because sometimes you can accidentaly have a resource fork (like a CKID resource) onto a plain binary file (for example on a CW project, a GIF file...). If you want to add files types to be handled as plain binary, go to the preferences and add a new type.

Note : The resource fork on a text file is ignored. If you want to keep the resource fork of a text file, force to add the file as binary : but you won't be able to use this file on others platforms.

## 2.4 The "import" problem

The import command in cvs should be seen as inconsistent since it imports initially all the files as text files (so it makes a line feed conversion between the client and the server).

When the initial import is done and all the binary files have the binary attribute, the server and the client agree to not convert this files and everything is working finely.

So the problem appears ONLY during the first import, and cvs user know that the initial import is THE main difficulty with cvs.

Happy-fully, there are some turn-around :

- Make the initial import directly from the cvs server machine (for now on Unix or Windows platforms). But be careful with the line feeds automatic translation when you copy files from and to !
- Use the cvs wrappers file to mark extensions as binary. But you'll still not be able to import from the client since all the files are initially transfered as text to the server.
- Use the -W option of cvs import : the problem is that you have to figure yourself all the extensions to map to a binary format (the -W option works this way : you can tell cvs that an extension, .gif for example, represents a set of binary file). My experience shows you can make a lot of errors this way.

That's why the MacCVS port was implemented for :

- Using the import command of the MacCVS client, you'll be able to have a dialog which tells you the current binary mapping and let you modify it. It detects also a lot of common errors and sometimes warn you about something you may care about.
- When you hit continue, MacCVS will prepare automatically the line command to cvs with the binary wrappers you want to use.
- Finally you can import safely. Both the client and the server will know exactly which files are binary and which one are text.

Very important note : You still have to set the binary preferences in order to force MacCVS to send the files as plain-binary to the server.

Very important note 2 : When you use plain binary files, be sure to have Internet Config well-configured for these files : if not, you may loose your plain binary representation and won't be able to open these files on others platforms (since they would be mac-encoded).

## 2.5 Getting started

- Be sure to be familiar with the import problem.
- While you use CVS, make sure your Internet Config is always up-to-date when using plain-binary files or if you set the Internet Config option for text.
- Set in the preferences the CVSROOT and the kind of authentication.
- If you create a new module using the import command, use first carefully the report and fix all the errors or conflicts.
- Use the online-help available on most of the menu entries or dialogs by activating "Show ballons" in the help menu (unavailable on MacCVS 3.1).

## 2.6 Hacking MacCvs

The MacCvs port consists in :

- A shared library with a MixedMode interface which contains the cvs code and mimic the cvs command line. This architecture allows to re-initialize the globals of cvs as well to separate really the implementation of the client and cvs.
- An application which implements a UI, Apple Events, a console and call the shared library to make the stuff.

What I've done after is to change a little bit client.c to oblige the client to convert the file whenever it sends it to the server. This allows to encode/decode the files in HQX format and also the disable/enable the line feed conversion when the file is flat (no resource fork) and is not a text file.