Files Command
This request is sent by the Krugle Enterprise to synchronize itself with the latest files available on the SCMI. Depending on if lastFilesCheckpoint is present in the request, this comment can represent either a request for all the files, or just the changes since the given lastFilesCheckpoint token. In SVN terms, sending a request without a lastFilesCheckpoint is asking for a “checkout”, while including the lastFilesCheckpoint is asking for an “update” from that point.
A checkpoint is an arbitrary string chosen by the SCMI to represent a point in time. The SCMI returns a checkpoint with the Files response, expecting the KE to store it and send it back with the next Files request (as well as next History request, see next section). For example in SVN you could use the repository revision for the checkpoint. Using the lastFilesCheckpoint field correctly will make the files update process efficient because generally less files will have to be retrieved. Although the field is required in the files response, it can be set to anything and ignored, if the SCMI author wishes.
Use UTF-8 encoding for all XML communications between Krugle Enterprise and the SCMI script. File URLs sent from the SCMI to Krugle (http, https or scp) must be URL encoded.
Call
- xml
- Comments
<files-request version=”1”>
<project>
<serverUid>Server1</serverUid> <projectUid>Project1</projectUid> svn://svn.host.net/repo
<params>u$3rn4m3 p4$$w0rd</params> </project>
<lastFilesCheckpoint>2311 </lastFilesCheckpoint>
</files-request>-
The
“serverUid”element will contain an identifier unique to each KE Appliance.The
“projectUid”element will contain a string which identifies this project uniquely in the scope of the KE Appliance.The
“location”is the user defined text provided as part of the KE Appliances’s project configuration. It should give a path to the resources the SCMI will process.The
“params”is another string which is defined by the user in the project configuration. It should specify any information needed in addition to the location, like credentials.The
“lastFilesCheckpoint”is the token that was returned as part of the last update response. If this token is omitted the call, the response will include the full list of current files.
Response
- xml
- Comments
<?xml version=”1.0” encoding=”UTF-8”?> <files-response version=”1”> <project> <serverUid>Server1</serverUid> <projectUid>Project1</projectUid> <location> svn://svn.host.net/repo </location> <params>u$3rn4m3 p4$$w0rd</params> </project> <files> <file> <action>ADDED</action> <name>/path/to/file.txt</name> <url>http://server:port/root/path/to/file. txt</url> <md5> d41d8cd98f00b204e9800998ecf8427e </md5> <revision>345</revision> </file> <file> ... </file> </files> <filesCheckpoint>2601</filesCheckpoint> </files-response>-
Zero or one
“files”elements may be present.Zero or more
“file”elements may be present in each “files” elements.The
“action”must be “Added”, “Removed” or “Updated”.The
“name”element contains the path of the file relative to the project root.
The
“URL”element contains the full URL that can be used to retrieve the file / record. Not present for files that are being REMOVED.
Examples of well formed URLs: “http://server1:80/java/com/krugle/helper/save.txt” or “ftp://public:password@ftp1:21/java/com/ krugle/helper/save.txt” or “SSH://server:port/command java/com/krugle/helper/save.txt”
OPTIONAL: If present, the “revision” element contains a revision string which will be added to the index.
OPTIONAL: If present, the “md5” element contains the MD5 hash of the file contents, but the md5 element can be omitted.
The
“filesCheckpoint”is the token which the KE will store and send back to the SCMI in the next files-request in the lastFilesCheckpoint.