Improve it

bugs / todo list
bugs
mailing list
IRC (logs)
wiki
self-hosting info
savannah
self-hosting info
browse source
latest work (RSS)
commit mailing list:
============================================================ --- wiki/AlternativeOverview.mdwn 527af6d692dfc2fc3eb9a05a52c612c52e56eec3 +++ wiki/AlternativeOverview.mdwn c4c211a67e6a21c00468d6783c62ece443eb2112 @@ -1,7 +1,7 @@ [[tag migration-auto]] -*(Though there is a [Monotone manual](http://venge.net/monotone/docs/index.html), this alternative presentation of concepts may be of use. It might be possible to refine this into an article that is the appropriate size, scope, and neutrality to be suited for integration into the [Monotone Wikipedia article](http://en.wikipedia.org/wiki/Monotone_%28software%29).)* +*(Though there is a [Monotone manual](http://monotone.ca/docs/index.html), this alternative presentation of concepts may be of use. It might be possible to refine this into an article that is the appropriate size, scope, and neutrality to be suited for integration into the [Monotone Wikipedia article](http://en.wikipedia.org/wiki/Monotone_%28software%29).)* ## P2P Database Basics @@ -12,13 +12,13 @@ Each archive snapshot is called a *revis Each archive snapshot is called a *revision*. A directory can be added into the *monotone database* using a command called **setup**. When a new *revision* has been *setup* into a *monotone database*, a number known as a *revision ID* is automatically generated to identify it. '''(eds: technically, setup remembers what database you want to associate with, but can't generate a revision id yet. revision id's are only ever generated by a commit)''' -Unlike adding files to a ".zip" or a ".tar", a directory that has been *setup* into a *monotone database* retains a connection to that database and is known as a **workspace**. Hidden files in the *workspace* are used to remember the *revision id* that was generated. Because monotone remembers what files were extracted, you can issue a command called *commit* to generate another *revision* using the same list of files (unless told to do otherwise). +Unlike adding files to a ".zip" or a ".tar", a directory that has been *setup* into a *monotone database* retains a connection to that database and is known as a **workspace**. Hidden files in the *workspace* are used to remember the *revision id* that was generated. Because monotone remembers what files were extracted, you can issue a command called *commit* to generate another *revision* using the same list of files (unless told to do otherwise). ### Extracting Once a *revision ID* is known, you may extract the archive that corresponds to that *revision* into a directory, using a command called **checkout**. If you want to extract an archive into a directory that already exists...use the **update** command. Just as with *setup*, performing a *checkout* or *update* keeps a connection between a *workspace* and a *monotone database*. '''(eds: er, you can update in a workspace that already exists. i don't believe you can run update in any old directory and have it work.)''' - + ### Transferring *Revisions* can be transferred from one *monotone database* into another. The monotone application is able to run as a server and accept requests from another instance of monotone running as a client. These client requests can **push** *revisions* from the client's *monotone database* into one residing on the server. They can also **pull** *revisions* from the server and into a *monotone database* managed by the client. @@ -38,7 +38,7 @@ Security and network authorization in Mo ## Versioning in Monotone -Most of Monotone's interesting features are enabled by tracking a concept of how one *revision* relates to another in conceptual sequence. +Most of Monotone's interesting features are enabled by tracking a concept of how one *revision* relates to another in conceptual sequence. '''(eds: technically the set of revisions forms a directed acyclic graph. don't know if that's appropriate to point out for your target audience or not. the fact that it is *acyclic* does matter though.)''' ### Hierarchy ============================================================ --- wiki/AutomateVersions.mdwn edb374f9132c00e660d894412ad164f7ea2f4015 +++ wiki/AutomateVersions.mdwn 5e5c9446f164e786bf36b07984cf3f1c5c32e3d6 @@ -11,60 +11,65 @@ This table shows all interface versions This table shows all interface versions to date and the particular monotone releases which implemented them: [[!table data=""" -interface versions | 0.0 | 0.1 | 0.2 | 1.0 | 1.1 | 2.0 | 2.1 | 2.2 | 3.0 | 3.1 | 4.0 | 4.1 | 4.3 | 5.0 | 6.0 | 7.0 | -monotone releases | 0.17 | 0.18 | 0.19 | 0.20-0.23 | 0.24-0.25 | 0.26 | 0.27 | 0.28 | 0.29 | 0.30 | 0.31-0.33 | 0.34 | 0.35 | 0.36 | 0.37-0.38 | 0.39-0.40 | +interface versions | 0.0 | 0.1 | 0.2 | 1.0 | 1.1 | 2.0 | 2.1 | 2.2 | 3.0 | 3.1 | 4.0 | 4.1 | 4.3 | 5.0 | 6.0 | 7.0 | 8.0 | 9.0 | +monotone releases | 0.17 | 0.18 | 0.19 | 0.20-0.23 | 0.24-0.25 | 0.26 | 0.27 | 0.28 | 0.29 | 0.30 | 0.31-0.33 | 0.34 | 0.35 | 0.36 | 0.37-0.38 | 0.39-0.40 | 0.41 | 0.42 | """ ]] The following table gives you an overview at which time certain functionalities have been added or altered in monotone's automation interface: [[!table data=""" -interface versions | 0.0 | 0.1 | 0.2 | 1.0 | 1.1 | 2.0 | 2.1 | 2.2 | 3.0 | 3.1 | 4.0 | 4.1 | 4.3 | 5.0 | 6.0 | 7.0 ¹| -ancestors | | | A | | | | | | | | | | | | | | -ancestry\_difference | | A | | | | | | | | | | | | | | | -branches | | | | | | | | A | | | | | | | | | -cert | | | | | | | | | | | | A | | | | | -certs | | | | A | | | | | | | | | | | | | -children | | | A | | | | | | | | | | | | | | -common\_ancestors | | | | | | | A | | | | | | | | | | -content\_diff | | | | | | | | | | | | | | | | | -descendents | | A | | | | | | | | | | | | | | | -drop\_attribute | | | | | | | | | | | | | | A | | | -drop\_db\_variables | | | | | | | | | | | | | | | | A | -erase\_ancestors | | A | | | | | | | | | | | | | | | -genkey | | | | | | | | | | | | | | | | | -get\_attributes | | | | | | | | | A | | | | | C | | | -get\_base\_revision\_id | | | | | | A | | | | | | | | | | | -get\_content\_changed | | | | | | | | | | | A | | | | | | -get\_corresponding\_path | | | | | | | | | | | A | | | | | | -get\_current\_revision | | | | | | | | | | | | | | | | A | -get\_current\_revision\_id | | | | | | A | | | | | | | | | | | -get\_db\_variables | | | | | | | | | | | | A | | | | C | -get\_file | | | | A | | | | | | | | | | | | | -get\_file\_of | | | | | | | | | | | | | | | | | -get\_manifest\_of | | | | | | A | | | | | | | | | | | -get\_option | | | | | | | | | | A | | | | | | | -get\_revision | | | | A | | | | | | | | | | | | C | -graph | | | A | | | | | | | | | | | | | | -heads | A | | | | | | | | | | | | | | | | -identify | | | | | | | | | | | | | A | | | | -interface\_version | A | | | | | | | | | | | | | | | | -inventory | | | | A | | | | | | | | | | | C | C | -keys | | | | | A | | | | | | | | | | | | -leaves | | A | | | | | | | | | | | | | | | -packet\_for\_fdata | | | | | | A | | | | | | | | | | | -packet\_for\_fdelta | | | | | | A | | | | | | | | | | | -packet\_for\_rdata | | | | | | A | | | | | | | | | | | -packets\_for\_certs | | | | | | A | | | | | | | | | | | -parents | | | A | | | | | | | | | | | | | | -put\_file | | | | | | | | | | | | A | | | | | -put\_revision | | | | | | | | | | | | A | | | | | -roots | | | | | | | | | | | | | A | | | | -select | | | A | | | | | | | | | | | | | | -set\_attribute | | | | | | | | | | | | | | A | | | -set\_db\_variable | | | | | | | | | | | | A | | | | C | -stdio | | | | A | | | | | | B | | | | | | | -tags | | | | | | | | A | | | | | | | | | -toposort | | A | | | | | | | | | | | | | | | +interface versions | 0.0 | 0.1 | 0.2 | 1.0 | 1.1 | 2.0 | 2.1 | 2.2 | 3.0 | 3.1 | 4.0 | 4.1 | 4.3 | 5.0 | 6.0 | 7.0 ¹| 8.0 | 9.0 | +ancestors | | | A | | | | | | | | | | | | | | | | +ancestry\_difference | | A | | | | | | | | | | | | | | | | | +branches | | | | | | | | A | | | | | | | | | | | +cert | | | | | | | | | | | | A | | | | | | | +certs | | | | A | | | | | | | | | | | | | | | +children | | | A | | | | | | | | | | | | | | | | +common\_ancestors | | | | | | | A | | | | | | | | | | | | +content\_diff | | | | | | | | | | | | | | | | | | B | +descendents | | A | | | | | | | | | | | | | | | | | +drop\_attribute | | | | | | | | | | | | | | A | | | | | +drop\_db\_variables | | | | | | | | | | | | | | | | A | | | +erase\_ancestors | | A | | | | | | | | | | | | | | | | | +file\_merge | | | | | | | | | | | | | | | | | | A | +genkey | | | | | | | | | | | | | | | | | | | +get\_attributes | | | | | | | | | A | | | | | C | | | | | +get\_base\_revision\_id | | | | | | A | | | | | | | | | | | | | +get\_content\_changed | | | | | | | | | | | A | | | | | | | | +get\_corresponding\_path | | | | | | | | | | | A | | | | | | | | +get\_current\_revision | | | | | | | | | | | | | | | | A | | | +get\_current\_revision\_id | | | | | | A | | | | | | | | | | | | | +get\_db\_variables | | | | | | | | | | | | A | | | | C | | | +get\_file | | | | A | | | | | | | | | | | | | | | +get\_file\_of | | | | | | | | | | | | | | | | | | | +get\_manifest\_of | | | | | | A | | | | | | | | | | | | | +get\_option | | | | | | | | | | A | | | | | | | | | +get\_revision | | | | A | | | | | | | | | | | | C | | | +get\_workspace\_root | | | | | | | | | | | | | | | | | A | | +graph | | | A | | | | | | | | | | | | | | | | +heads | A | | | | | | | | | | | | | | | | | | +identify | | | | | | | | | | | | | A | | | | | | +interface\_version | A | | | | | | | | | | | | | | | | | | +inventory | | | | A | | | | | | | | | | | C | C | C | | +keys | | | | | A | | | | | | | | | | | | | | +leaves | | A | | | | | | | | | | | | | | | | | +lua | | | | | | | | | | | | | | | | | | A | +packet\_for\_fdata | | | | | | A | | | | | | | | | | | | | +packet\_for\_fdelta | | | | | | A | | | | | | | | | | | | | +packet\_for\_rdata | | | | | | A | | | | | | | | | | | | | +packets\_for\_certs | | | | | | A | | | | | | | | | | | | | +parents | | | A | | | | | | | | | | | | | | | | +put\_file | | | | | | | | | | | | A | | | | | | | +put\_revision | | | | | | | | | | | | A | | | | | | | +read\_packets | | | | | | | | | | | | | | | | | | A | +roots | | | | | | | | | | | | | A | | | | | | +select | | | A | | | | | | | | | | | | | | | | +show\_conflicts | | | | | | | | | | | | | | | | | A | C | +set\_attribute | | | | | | | | | | | | | | A | | | | | +set\_db\_variable | | | | | | | | | | | | A | | | | C | | | +stdio | | | | A | | | | | | B | | | | | | | | | +tags | | | | | | | | A | | | | | | | | | | | +toposort | | A | | | | | | | | | | | | | | | | | """ ]] ###Legend ============================================================ --- wiki/Building/Windows/VisualC8.mdwn c14fc83752478ffb9a1778980aa6a00a37dcd7bc +++ wiki/Building/Windows/VisualC8.mdwn 68a28e36ecc52965bc1d547168378717661fe641 @@ -35,8 +35,8 @@ zlib|1.2.3| 7. switched from CVS to mtn about half a year ago +8. can now be found in the i2p.syndie branch of the I2P repo ## Tips ============================================================ --- wiki/QuickieTasks.mdwn c39f95792b259543cc95a4ff735f3686673c51f6 +++ wiki/QuickieTasks.mdwn 6218370b9e1146588b2c0f65a25ac537e621cd9a @@ -14,8 +14,6 @@ So, here are some smaller tasks, that ve * `mtn rename --guess` -- try to figure out what files have been renamed by matching up missing and unknown files with the same checksums - * `mtn list duplicates` -- list files that have the same checksum (duplicate content) in a given revision (or the workspace) - * `mtn clean --unknown --ignored` to remove files of each type from the workspace; handy for a really aggressive "make clean", and for plaforms without xargs or where there might be spaces in filenames so that `mtn ls unknown | xargs rm` is hard or dangerous. * `mtn diff --ignore-whitespace` ============================================================ --- wiki/SurveyQuestions.mdwn a3ec3be0f6f9978e3e0e8ca2930ece94cb193c05 +++ wiki/SurveyQuestions.mdwn abaad1f980b02c19cf53af735ed2b412a9652836 @@ -41,7 +41,7 @@ Questions we should consider asking the * How much memory and CPU speed do the machine(s) you normally run monotone on have? - * Where do you get your monotone binaries? (E.g., by downloading source from venge.net, from the binary downloads on venge.net, from a distribution (if so, which?), etc.) + * Where do you get your monotone binaries? (E.g., by downloading source from monotone.ca, from the binary downloads on monotone.ca, from a distribution (if so, which?), etc.) * Do you use inodeprints? Do you know that inodeprints exists? ============================================================ --- wiki/ikiwiki_migration.mdwn 92016357fffd2c431959c95bb8ad3402c3ae37f4 +++ wiki/ikiwiki_migration.mdwn 489f79fa259fce5b5c02a6ad7cf4f97b23b9e03c @@ -4,6 +4,8 @@ 1. fetch the page you're going to migrat markup style, into the workspace, and commit it as is for reference. (adjust as needed for some other tool, like wget or curl). + ATTENTION: The moinmoin wiki was shutdown on 2008-12-16, so this no longer works + ftp -o ZipperMerge.moin "http://www.venge.net/mtn-wiki/ZipperMerge?action=raw" mtn add ZipperMerge.moin mtn commit @@ -43,7 +45,7 @@ 3. Translate the markup. *Some of this m of single-quotes * Links are done with `\[[SquareBrackets]]` rather than bare - `[[CamelCaseWords]]` + `[[CamelCaseWords]]` * preformatted code blocks are done with 4 more spaces (inside the current level of indentation, say when inside nested lists), @@ -53,7 +55,7 @@ 3. Translate the markup. *Some of this m rather than `[http://url link text]` An exception: when the URL is the link text as well, it can be - simplified like this: `` + simplified like this: `` The angle brackets are *required* in this case. Ikiwiki and markdown do not make any attempt to interpret URLs otherwise.