VCS::LibCVS::WorkingFile.3pm

Langue: en

Autres versions - même langue

Version: 2005-10-10 (fedora - 01/12/10)

Section: 3 (Bibliothèques de fonctions)

NAME

VCS::LibCVS::WorkingFile - A file checked out of CVS.

SYNOPSIS

DESCRIPTION

This object represents a local copy of a file checked out from CVS.

SUPERCLASS

VCS::LibCVS::WorkingFileOrDirectory

CLASS ROUTINES

new()

$working_file = VCS::LibCVS::WorkingFile->new($filename)
return type: VCS::LibCVS::WorkingFile
argument 1 type: scalar string
The name of the file which is under CVS control.

Creates a new WorkingFile. The filename may be relative or absolute, and is stored as such.

It throws an exception if the file is not recorded in the CVS/Entries file.

INSTANCE ROUTINES

get_remote_object()

$r_file = $w_file->get_remote_object()
return type: VCS::LibCVS::RepositoryFile
Returns the remote CVS file associated with this working file.

It reads the CVS sandbox administrative directory to get this info.

get_branch()

$branch = $w_file->get_branch()
return type: VCS::LibCVS::Branch
Returns the branch this local file is on.

If there is no sticky branch tag, it returns the MAIN branch.

get_file_branch()

$file_branch = $w_file->get_file_branch()
return type: VCS::LibCVS::FileBranch
Returns the file branch this local file is on.

The branch is determined by looking at any sticky branch tags, and then at the revision number.

If a branch has a sticky non-branch tag, then there can be amibiguity about which branch the revision is on. For instance, revision 1.4 could be the fourth revision on branch 1 (the trunk), or it could be the initial revision of branch 1.4.2. The best way to resolve this ambiguity would be to examine the rest of the files in the repository to determine which branch the non-branch tag lies on. Such an algorithm is not implemented here, instead the parent branch is always assumed. This is important to consider in the common case of base tags for branches.

get_directory_of()

$w_file->get_directory_of()
return type: VCS::LibCVS::WorkingDirectory

Returns the working directory containing this object. If the directory isn't under CVS control, or if the object's specification is relative, and it's parent directory can't be determined, an exception is thrown.

get_scheduled_action()

$w_file->get_scheduled_action()
return type: integer, one of VCS::LibCVS::WorkingFile::ACTION_*

Returns any action which has been scheduled on this file. The actions are:

   ACTION_NONE
   ACTION_ADD
   ACTION_REMOVE
 
 

get_state()

$w_file->get_state()
return type: one of VCS::LibCVS::WorkingFile::STATE_*

Returns the state of the local file. This is determined with reference to the information in the Admin directory, including any scheduled actions. The possible states are:

   STATE_UPTODATE
   STATE_MODIFIED
   STATE_HADCONFLICTS
   STATE_ABSENT
 
 

In the case of a file which has been scheduled for removal, it should not appear in the working directory, so being absent is treated as uptodate. If it is present, it is reported as modified.

get_rstate()

$w_file->get_rstate()
return type: one of VCS::LibCVS::WorkingFile::STATE_*

Returns the state of the repository with respect to the working file info. This is determined with reference to the information in the Admin directory, including any scheduled actions. The possible states are:

   STATE_UPTODATE
   STATE_MODIFIED
   STATE_ABSENT
   STATE_WILLCONFLICT
 
 

get_revision_number()

$w_file->get_revision_number()
return type: VCS::LibCVS::Datum::RevisionNumber

Return the revision number of the local file.

When a file was imported and then checked out on the trunk, it will have a revision number of 1.1.1.1, and no sticky tag, and actually reside on the trunk. This routine will hack that case to retun the revision 1.1.

SEE ALSO

   VCS::LibCVS