SHA1 Hash:	9d704470c336fd97967914c44c63d38b6ce688c7
Date:	2008-12-13 13:40:44
User:	kejoki
Comment:	added specification, subsystems to ticket choices, zorro-ed a spelling error
Timelines:	ancestors | descendants | both | trunk
Other Links:	files | ZIP archive | manifest

• branch=trunk inherited from [a28c83647d]
• sym-trunk inherited from [a28c83647d]

Modified ci_fossil.txt from [2064b7fe7f] to [cf2b7a00fb].

@@ -35,16 +35,16 @@
 The disadvantage of this method is however that it will gobble up a
 lot of temporary space in the filesystem to hold all unique revisions
 of all files in their expanded form.
 
 It might be worthwhile to consider an extension of 'reconstruct' which
-is able to incrementally add a set of files to an exiting fossil
+is able to incrementally add a set of files to an existing fossil
 repository already containing revisions. In that case the import tool
 can be changed to incrementally generate the collection for a
 particular revision, import it, and iterate over all revisions in the
 origin repository. This is of course also dependent on the origin
-repository itself, how good it supports such incremental export.
+repository itself, how well it supports such incremental export.
 
 This also leads to a possible method for performing the import using
 only existing functionality ('reconstruct' has not been implemented
 yet). Instead generating an unordered collection for each revision
 generate a properly setup workspace, simply commit it. This will