Fossil SCM
added specification, subsystems to ticket choices, zorro-ed a spelling error
Commit
9d704470c336fd97967914c44c63d38b6ce688c7
Parent
bab836387661744…
1 file changed
+2
-2
+2
-2
| --- ci_fossil.txt | ||
| +++ ci_fossil.txt | ||
| @@ -35,16 +35,16 @@ | ||
| 35 | 35 | The disadvantage of this method is however that it will gobble up a |
| 36 | 36 | lot of temporary space in the filesystem to hold all unique revisions |
| 37 | 37 | of all files in their expanded form. |
| 38 | 38 | |
| 39 | 39 | It might be worthwhile to consider an extension of 'reconstruct' which |
| 40 | -is able to incrementally add a set of files to an exiting fossil | |
| 40 | +is able to incrementally add a set of files to an existing fossil | |
| 41 | 41 | repository already containing revisions. In that case the import tool |
| 42 | 42 | can be changed to incrementally generate the collection for a |
| 43 | 43 | particular revision, import it, and iterate over all revisions in the |
| 44 | 44 | origin repository. This is of course also dependent on the origin |
| 45 | -repository itself, how good it supports such incremental export. | |
| 45 | +repository itself, how well it supports such incremental export. | |
| 46 | 46 | |
| 47 | 47 | This also leads to a possible method for performing the import using |
| 48 | 48 | only existing functionality ('reconstruct' has not been implemented |
| 49 | 49 | yet). Instead generating an unordered collection for each revision |
| 50 | 50 | generate a properly setup workspace, simply commit it. This will |
| 51 | 51 |
| --- ci_fossil.txt | |
| +++ ci_fossil.txt | |
| @@ -35,16 +35,16 @@ | |
| 35 | The disadvantage of this method is however that it will gobble up a |
| 36 | lot of temporary space in the filesystem to hold all unique revisions |
| 37 | of all files in their expanded form. |
| 38 | |
| 39 | It might be worthwhile to consider an extension of 'reconstruct' which |
| 40 | is able to incrementally add a set of files to an exiting fossil |
| 41 | repository already containing revisions. In that case the import tool |
| 42 | can be changed to incrementally generate the collection for a |
| 43 | particular revision, import it, and iterate over all revisions in the |
| 44 | origin repository. This is of course also dependent on the origin |
| 45 | repository itself, how good it supports such incremental export. |
| 46 | |
| 47 | This also leads to a possible method for performing the import using |
| 48 | only existing functionality ('reconstruct' has not been implemented |
| 49 | yet). Instead generating an unordered collection for each revision |
| 50 | generate a properly setup workspace, simply commit it. This will |
| 51 |
| --- ci_fossil.txt | |
| +++ ci_fossil.txt | |
| @@ -35,16 +35,16 @@ | |
| 35 | The disadvantage of this method is however that it will gobble up a |
| 36 | lot of temporary space in the filesystem to hold all unique revisions |
| 37 | of all files in their expanded form. |
| 38 | |
| 39 | It might be worthwhile to consider an extension of 'reconstruct' which |
| 40 | is able to incrementally add a set of files to an existing fossil |
| 41 | repository already containing revisions. In that case the import tool |
| 42 | can be changed to incrementally generate the collection for a |
| 43 | particular revision, import it, and iterate over all revisions in the |
| 44 | origin repository. This is of course also dependent on the origin |
| 45 | repository itself, how well it supports such incremental export. |
| 46 | |
| 47 | This also leads to a possible method for performing the import using |
| 48 | only existing functionality ('reconstruct' has not been implemented |
| 49 | yet). Instead generating an unordered collection for each revision |
| 50 | generate a properly setup workspace, simply commit it. This will |
| 51 |