
	This is a technical description of the way file synchronization works in the RON 
	 (Repository Object Navigator) of Oracle Repository.<P>It is assumed that normally,
	 any editing of the file's contents is done using filesystem facilities (editors,
	 graphics tools, for example), and that the repository is used for managing versions
	 of the contents (creating versions, comparing and merging, for example).</P><P>Synchronization
	 is a scheme for keeping the contents of operating system files in step with their
	 equivalents in the repository, and vice versa, so that when one set of contents changes,
	 the other set of contents are refreshed to reflect the changes. Synchronization can
	 therefore either cause the file system be refreshed from the repository (download),
	 or cause the repository contents to be refreshed from the file system (upload). </P><P>One
	 of two approaches to synchronization can be adopted by the caller: <BR><BR><UL>
	  <LI>Mapped - This uses a pre-defined folder mapping between    a root container
	 in the repository and a corresponding operating system folder. <BR>    <BR>  </LI>
	  <LI>Unmapped - This does not require a folder mapping: the File Service uses a
	 supplied    repository path and file system path to perform the synchronization.
	 </LI></UL><P><STRONG>Notes:</STRONG> <BR><BR><OL>  <LI>Synchronization is not automatic.
	 The calling application must schedule a call to    perform the synchronize operation
	 explicitly according to its own requirements (for    example, in response to a user
	 request, or when a check-in or checkout operation is    performed). <BR>    <BR>
	  </LI>  <LI>The repository used for synchronization is the one specified in the
	 RepositoryConnection Object created by each FileService object. <BR>    <BR>  </LI>
	  <LI>The decision about whether to upload or download is determined by establishing
	 which    'edition' of a file has most recently changed. The most recently changed
	 edition replaces    any other edition. <BR>    <BR>  </LI>  <LI>All operations described
	 here require a context workarea to be set. <BR>    <BR>  </LI>  <LI>The contents
	 of a file are stored into the CONTENTS_CLOB, CONTENTS_BLOB, or    COMPRESSED_CONTENTS
	 column of a PRIMARY_ACCESS_FILE object in the repository, depending on    whether
	 the file's type is defined in the File Type Registry  (FTR) as text, binary,  
	  or compressed. If the file's name matches a pattern defined in the File Type Registry
	 as    COMPRESSED, uploading compresses the file before storing it in the repository,
	 and    decompresses the contents before downloading. <BR>    <BR>  </LI>  <LI>In
	 general, the repository definitions of container objects are not updated by upload
		and download operations. The exception is where the caller specifies that a folder
	 that    has new files added to it must be versioned).  </LI></OL>
	