A snapshot is a record of the revision level of a content spec and the revision levels of all the topics in it, at a point in time. A snapshot has a name, and is linked to a content spec. When a snapshot is created, the current time and date are recorded. Create a snapshot: skynet snapshot <ContentSpec.ID> --name <snapshot.name> Example: skynet snapshot 6 --name Beta Release List snapshots for a Content Spec: skynet list -cs <ContentSpec.ID> Example: skynet list -cs 6 Snapshot ID Snapshot Date Snapshot name 1 11-11-02 Beta Release Build an output book using the Content Spec and Topics from the snapshot: skynet build <ContentSpec.ID> -s <Snapshot.ID> Example: skynet build 6 -s 1
Added. There is one extra database table required for snapshots (two if you include the audited table). This table is used to store the snapshot information. There is no foreign key on the ScopeID field because envers will increase the revision ID for the content specification when persisting a new snapshot for a Content Specification. This is unwanted as it makes it much more difficult to edit a content specification due to the SpecRevision attribute. The syntax is slightly different for the list commands. The syntax to use for the list command is: // For a list of snapshots for a specific content specification skynet list -s <ContentSpec.ID> or // For a list of all snapshots skynet list -s If the server is set-up in standalone.xml (See the property below or the description in the 0.19.0 release tracker), then a snapshot will also be created using the skynet snapshot system. This snapshot is stored but never used within the csprocessor at this stage. <property name="csprocessor.create-topic-snapshots" value="true"/> Snapshots can be built using the syntax previously specified. Doing so will use the revision numbers stored for the snapshot to pull the data from the database, so that the data is in the same state it was at the time of the snapshot.
Currently disabled. This depends on snapshots being implemented in Skynet. The workaround at this point in time is to do an assembly, then check the assembly into an svn branch. That functions as the snapshot.
If it becomes necessary before that's locked down, another method would be to allow a version of the Content Spec to be pulled that contains the rev levels of the topics, and to allow a Content Spec of this format to build. So taking a snapshot would be a case of writing out and saving a Content Spec with a format like: Topic Title [<ID> r:<REV>]
Minor update to Josh's last comment. Instead of adding the revision for each topic, all that would be required is to specify the revision of the content specification to be built. eg "csprocessor build <ID> -r <REV>"
Scrub the previous comment. If you repush the Content Spec and then build the release immediately, then the revision of the Content Spec that you build from is sufficient data to act as a snapshot. There is nowhere to store this revision number at this point, so you'll have to keep it in another system like svn, RT3, or BZ. To rebuild that snapshot requires re-enabling csprocessor with the -r switch. So, the workaround is: To create a snapshot 1. Repush the Content Spec. 2. Build the release immediately after repushing 3. Copy the build into an svn tag 4. Store the revision level of the Content Spec in svn along with the publican artifacts
This is implemented as "csprocessor pull-snapshot" in the 0.27 of csprocessor. See csprocessor --help.
Closing this as it's no longer relevant to the current implementation.