Fossil

Check-in [9d704470]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:added specification, subsystems to ticket choices, zorro-ed a spelling error
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:9d704470c336fd97967914c44c63d38b6ce688c7
User & Date: kejoki 2008-12-13 13:40:44
Context
2008-12-14
22:54
Moved new tcksetup.c into checkout dir before commit, added rstats command to get stat page info from command line. check-in: cdbc3ab2 user: kejoki tags: newcmd_rstatus, trunk
2008-12-13
13:40
added specification, subsystems to ticket choices, zorro-ed a spelling error check-in: 9d704470 user: kejoki tags: trunk
2008-12-12
23:17
timeline command now supports a ?-t|--type TYPE? option to filter on specific event types. Fixed a memleak in the timeline command. check-in: bab83638 user: stephan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to ci_fossil.txt.

33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
database to fossil itself.

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
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.

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
require use of rm, add and update methods as well, to remove old and
enter new files, and point the fossil repository to the correct parent







|




|







33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
database to fossil itself.

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 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 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
require use of rm, add and update methods as well, to remove old and
enter new files, and point the fossil repository to the correct parent