tkcvs.1

TKCVS Source Code For CVS。

Re-reads the revision history of the file.
.TP
.I View:
Pressing this button displays a Tk text window containing the version of the file at Selection A.
.TP
.I Annotate:
This displays a window in which the file is shown with its lines highlighted according to when and by whom they were last revised.  In Subversion, it's also called "blame." 
.TP
.I Diff:
Pressing this button runs the "tkdiff" program to display the differences between version A and version B.
.TP
.I Merge:
To use this button, select a branch version of the file, other than the branch you are currently on, as the primary version (Selection A). The changes made along the branch up to that version will be merged into the current version, and stored in the current directory. Optionally, select another version (Selection B) and the changes will be from that point rather than from the base of the branch.  The version of the file in the current directory will be merged, but no commit will occur.  Then you inspect the merged files, correct any conflicts which may occur, and commit when you are satisfied.  Optionally, TkCVS will tag the version that the merge is from.  It suggests a tag of the form "mergefrom_<rev>_date."  If you use this auto-tagging function, another dialog containing a suggested tag for the merged-to version will appear.  It's suggested to leave the dialog up until you are finished, then copy-and-paste the suggested tag into the "Tag" dialog.  It is always a good practice to tag when doing merges, and if you use tags of the suggested form, the Branch Browser can diagram them. (Auto-tagging is not implemented in Subversion because, despite the fact that tags are "cheap," it's somewhat impractical to auto-tag single files.  You can do the tagging manually, however.)
.TP
.I View Tags:
This button lists all the tags applied to the file in a searchable text window.
.TP
.I Close:
This button closes the Log Browser. If no other windows are open, TkCVS exits.
.SS The View Options Menu
The View Menu allows you to control what you see in the branch diagram.  You can choose how much information to show in the boxes, whether to show empty revisions, and whether to show tags.  You can even control the size of the boxes.  If you are using Subversion, you may wish to turn the display of tags off.  If they aren't asked for they won't be read from the repository, which can save a lot of time.
.SP
.SH Merge Tool for CVS
.LP
The Merge Tool chooses a "representative" file in the current directory and diagrams the branch tags. It tries to pick the "bushiest" file, or failing that, the most-revised file. If you disagree with its choice, you can type the name of another file in the top entry and press Return to diagram that file instead.
.LP
The main purpose of this tool is to do merges (cvs update -j rev [-j rev]) on the whole directory. For merging one file at a time, you should use the Log Browser. You can only merge to the line (trunk or branch) that you are currently on. Select a branch to merge from by clicking on it. Then press either the "Merge" or "Merge Changes" button. The version of the file in the current directory will be over-written, but it will not be committed to the repository. You do that after you've reconciled conflicts and decided if it's what you really want.
.TP
.I Merge Branch to Current:
The changes made on the branch since its beginning will be merged into the current version.
.TP
.I Merge Changes to Current:
Instead of merging from the base of the branch, this button merges the changes that were made since a particular version on the branch. It pops up a dialog in which you fill in the version. It should usually be the version that was last merged.
.SP
.SH Module Browser
.LP
Operations that are performed on the repository instead of in a checked-out working directory are done with the Module Browser.  The most common of these operations is checking out or exporting from the repository.  The Module Browser can be started from the command line (tkcvs -win module) or started from the main window by pressing the big button.
.LP
Subversion repositories can be browsed like a file tree, and that is what you will see in the Module Browser.  CVS repositories aren't directly browsable, but if the CVSROOT/modules file is maintained appropriately, TkCVS can display the modules and infer tree structures if they are present. See the "CVS Modules File" section.
.LP
Using the module browser window, you can select a module to check out. When you check out a module, a new directory is created in the current working directory with the same name as the module.
.SS Tagging and Branching (cvs rtag)
.LP
You can tag particular versions of a module or file in the repository, with plain or branch tags, without having the module checked out.
.SS Exporting
.LP
Once a software release has been tagged, you can use a special type of checkout called an export. This allows you to cleanly check out files from the repository,  without all of the administrivia that CVS needs to have while working on the files. It is useful for delivery of a software release to a customer.
.SS Importing
.LP
TkCVS contains a special dialog to allow users to import new files into the repository. In CVS, new modules can be assigned places within the repository, as well as descriptive names (so that other people know what they are for).
.LP
When the Module Browser displays a CVS repository, the first column is a tree showing the module codes and directory names of all of the items in the repository. The icon shows whether the item is a directory (which may contain other directories or modules), or whether it is a module (which may be checked out from TkCVS). It is possible for an item to be both a module and a directory. If it has a red ball on it, you can check it out. If it shows a plain folder icon, you have to open the folder to get to the items that you can check out.
.LP
To select a module, click on it with the left mouse button. The right mouse button will perform a secondary selection, which is used only for Subversion diff and patch. To clear the selection, click on the item again or click in an empty area of the module column. There can only be one primary and one secondary selection.
.SS Repository Browser Buttons
.LP
The module browser contains the following buttons:
.TP
.I Who:
Shows which modules are checked out by whom.
.TP
.I Import:
This item will import the contents of the current directory (the one shown in the Working Directory Display) into the repository as a module. See the section titled Importing for more information.
.TP
.I File Browse:
Displays a list of the selected module's files. From the file list, you can view the file, browse its revision history, or see a list of its tags.
.TP
.I Check Out:
Checks out the current version of a module. A dialog allows you to specify a tag, change the destination, and so on.
.TP
.I Export:
Exports the current version of a module. A dialog allows you to specify a tag, change the destination, and so on. Export is similar to check-out, except exported directories do not contain the CVS or administrative directories, and are therefore cleaner (but cannot be used for checking files back in to the repository). You must supply a tag name when you are exporting a module to make sure you can reproduce the exported files at a later date.
.TP
.I Tag:
This button tags an entire module.
.TP
.I Branch Tag:
This creates a branch of a module by giving it a branch tag.
.TP
.I Patch Summary:
This item displays a short summary of the differences between two versions of a module.
.TP
.I Create Patch File:
This item creates a Larry Wall format patch(1) file of the module selected.
.TP
.I Close:
This button closes the Repository Browser. If no other windows are open, TkCVS exits.
.SP
.SH Importing New Modules
.LP
Before importing a new module, first check to make sure that you have write permission to the repository. Also you'll have to make sure the module name is not already in use.
.LP
To import a module you first need a directory where the module is located. Make sure that there is nothing in this directory except the files that you want to import.
.LP
Press the big "Repository Browser" button in the top part of the tkcvs UI, or use CVS -> Import WD into Repository from the menu bar.
.LP
In the module browser, press the Import button on the bottom, the one that shows a folder and an up arrow.
.LP
In the dialog that pops up, fill in a descriptive title for the module.  This will be what you see in the right side of the module browser.
.LP
OK the dialog.  Several things happen now.  The directory is imported, the CVSROOT/module file is updated, your original directory is saved as directory.orig, and the newly created module is checked out.
.LP
When it finishes, you should find the original Working Directory Browser showing the files in the newly created, checked out module.
.LP
Here is a more detailed description of the fields in the Import Dialog.
.TP
.I Module Name:
A name for the module.  This name must not already exist in the repository. Your organization could settle on a single unambiguous code for modules. One possibility is something like:
.LP
.RS
    [project code]-[subsystem code]-[module code]
.RE
.TP
.I Module Path:
The location in the repository tree where your new module will go.
.TP
.I Descriptive Title:
A one-line descriptive title for your module.  This will be displayed in the right-hand column of the browser.
.TP
.I Version Number:
The current version number of the module. This should be a number of the form X.Y.Z where .Y and .Z are optional. You can leave this blank, in which case 1 will be used as the first version number.
.LP
Importing a directory into Subversion is similar but not so complicated.  You use the SVN -> Import CWD into Repository menu.  You need supply only the path in the repository where you want the directory to go.  The repository must be prepared and the path must exist, however.
.SP
.SH Importing to an Existing Module (CVS)
.LP
Before importing to an existing module, first check to make sure that you have write permission to the repository.
.LP
To import to an existing module you first need a directory where the code is located. Make sure that there is nothing in this directory (including no CVS directory) except the files that you want to import.
.LP
Open up the Repository Browser by selecting File/Browse Modules from the menu bar.
.LP
In the Repository Browser, select File/Import To An Existing Module from the menu bar.
.LP
In the dialog that pops up, press the Browse button and select the name of an existing module. Press the OK to close this dialog box. Enter the version number of the code to be imported. 
.LP
OK the dialog.  Several things happen now.  The directory is imported, your original directory is saved as directory.orig, and the newly created module is checked out.
.LP
When it finishes, you will find the original Working Directory Browser showing the original code. If you press the "Re-read the current directory" button you will see the results of the checked out code.
.LP
Here is a more detailed description of the fields in the Import Dialog.
.TP
.I Module Name:
A name for the existing module. Filled in by the use of the the Browse button
.TP
.I Module Path:
The location in the repository tree where the existing module is. Filled in by the use of the Browse button. 
.TP
.I Version Number:
The current version number of the module to be imported. This should be a number of the form X.Y.Z where .Y and .Z are optional. You can leave this blank, in which case 1 will be used as the first version number.
.SP
.SH Vendor Merge (CVS)
.LP
Software development is sometimes based on source distribution from a vendor or third-party distributor. After building a local version of this distribution, merging or tracking the vendor's future release into the local version of the distribution can be done with the vendor merge command.
.LP
The vendor merge command assumes that a separate module has already been defined for the vendor or third-party distribution with the use of the "Import To A New Module" and "Import To An Existing Module" commands. It also assumes that a separate module has already been defined for the local code for which the vendor merge operation is to be applied to.
.LP
Start from an empty directory and invoke tkcvs. Open up the Repository Browser by selecting File/Browse Modules from the menu bar.
.LP
Checkout the module of the local code to be merged with changes from the vendor module. (Use the red icon with the down arrow)
.LP
In the Repository Browser, after verifying that the Module entry box still has the name the module of the local code to which the vendor code is to be merged into, select File/Vendor Merge from the menu bar.
.LP
In the Module Level Merge With Vendor Code window, press the Browse button to select the module to be used as the vendor module.
.LP
OK the dialog. All revisions from the vendor module will be shown in the two scroll lists. Fill in the From and To entry boxes by clicking in the appropriate scroll lists.
Ok the dialog. Several things happens now. Several screens will appear showing the output from cvs commands for (1)checking out temp files, (2)cvs merge, and (3)cvs rdiff. Information in these screens will tell you what routines will have merge conflicts and what files are new or deleted. After perusing the files, close each screen. .TP
.I (In the preceeding dialog box, there was an option to save outputs from the merge and rdiff operations to files CVSmerge.out and CVSrdiff.out.)
.LP
The checked out local code will now contain changes from a merge between two revisions of the vendor modules. This code will not be checked into the repository. You can do that after you've reconciled conflicts and decide if that is what you really want. 
.LP
A detailed example on how to use the vendor merge operation is provided in the PDF file vendor5readme.pdf. 
.SP
.SH Configuration Files
.LP
There are two configuration files for TkCVS. The first is stored in the directory in which the *.tcl files for TkCVS are installed. This is called tkcvs_def.tcl. You can put a file called site_def in that directory, too. That's a good place for site-specific things like tagcolours. Unlike tkcvs_def.tcl, it will not be overwritten when you install a newer version of TkCVS.
.LP
Values in the site configuration files can be over-ridden at the user level by placing a .tkcvs file in your home directory. Commands in either of these files should use Tcl syntax. In other words, to set a variable name, you should have the following command in your .tkcvs file:
.LP
.RS
    set variablename value
.RE
.LP
for example:
.LP
.RS
    set cvscfg(editor) "gvim"
.RE
.LP
The following variables are supported by TkCVS:
.SS Startup
.TP
.B cvscfg(startwindow)
Which window you want to see on startup. (workdir or module)
.TP
.B cvscfg(cvsroot)
If set, it overrides the CVSROOT environment variable.
.SS GUI
.LP
Most colors and fonts can be customized by using the options database. For example, you can add lines like these to your .tkcvs file:
.LP
.RS
   option add *Canvas.background #c3c3c3 
.RE
.RS
   option add *Menu.background #c3c3c3 
.RE
.RS
   option add *selectColor #ffec8b 
.RE
.RS
   option add *Text.background gray92 
.RE
.RS
   option add *Entry.background gray92 
.RE
.RS
   option add *Listbox.background gray92 
.RE
.RS
   option add *ToolTip.background LightGoldenrod1 
.RE
.RS
   option add *ToolTip.foreground black 
.RE
.TP
.B cvscfg(picklist_items)
Maximum number of visited directories and repositories to save in the picklist history
.SS Log browser