# # # patch "wiki/AutomateVersions.mdwn" # from [d45517368e9a74210f648e6c9904873bc6d773a0] # to [6a45f21f3ee5645c253f3643b0e737a578494b38] # # patch "wiki/Building/Windows.mdwn" # from [f79c0c4403eb2fe93cbc214129d57c5c77311235] # to [57a93afe2f78856f09e6b02c6f94d216958fe7d0] # # patch "wiki/DatabaseLocking.mdwn" # from [840b19f235d0cba2303bab02ac336070ece0bf3b] # to [6587493dd4538b573666e08ad3a6a85c35c40477] # ============================================================ --- wiki/AutomateVersions.mdwn d45517368e9a74210f648e6c9904873bc6d773a0 +++ wiki/AutomateVersions.mdwn 6a45f21f3ee5645c253f3643b0e737a578494b38 @@ -75,4 +75,4 @@ A = Addition, B = Backwards-compatible c 1 While the format of several command has not been changed between 0.39 and 0.40, the output of the commands (f.e. `automate inventory`) may differ because the interpretation of the --depth option changed in 0.40 (previously: 0 = the node + its immediate children, now: 0 = only this node) +If you like to get more information about certain command / format changes, please consult [[monotone's_Automation_documentation|docs/Automation.html]]. -If you like to get more information about certain command / format changes, please consult [monotone's Automation documentation](http://monotone.ca/docs/Automation.html). ============================================================ --- wiki/Building/Windows.mdwn f79c0c4403eb2fe93cbc214129d57c5c77311235 +++ wiki/Building/Windows.mdwn 57a93afe2f78856f09e6b02c6f94d216958fe7d0 @@ -1,6 +1,8 @@ +[[!tag migration-done]] + The officially supported build environment for monotone on Windows is [MinGW](http://mingw.org/). The exact requirements are listed [[in_the_specific_page|MinGW]]. -Building monotone under [Cygwin](http://cygwin.com/) is also known to work. monotone is also included as a package in all Cygwin mirrors and can be easily installed using [Cygwin's setup](http://cygwin.com/setup.exe). +Building monotone under [Cygwin](http://cygwin.com/) is also known to work. monotone is also included as a package in all Cygwin mirrors and can be easily installed using Cygwin's [setup.exe](http://cygwin.com/setup.exe). Building with Microsoft [Services For Unix](http://www.microsoft.com/windowsserversystem/sfu/default.mspx) is untested, but would probably work without too much difficulty. ============================================================ --- wiki/DatabaseLocking.mdwn 840b19f235d0cba2303bab02ac336070ece0bf3b +++ wiki/DatabaseLocking.mdwn 6587493dd4538b573666e08ad3a6a85c35c40477 @@ -1,28 +1,31 @@ -[[!tag migration-auto]] +[[!tag migration-done]] -*(source discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-12-08,Thu&sel=90#l151)* +*(source discussion: )* Discussion of database locking in Monotone, problems and suggested solutions. -When monotone code needs to start a transaction, it instansiates "transaction_guard". By default this leads to execution of the SQL statement "BEGIN EXCLUSIVE". Transaction guards can also be created in a non-exclusive mode; in this case "BEGIN DEFERRED" is run. This should only be done if it is believed no database writes will be performed. +When monotone code needs to start a transaction, it instansiates `transaction_guard`. By default this leads to execution of the SQL statement `BEGIN EXCLUSIVE`. Transaction guards can also be created in a non-exclusive mode; in this case `BEGIN DEFERRED` is run. This should only be done if it is believed no database writes will be performed. -We are trying to monotone bailing when a transaction involving writes is committed. "BEGIN EXCLUSIVE" guarantees that monotone will exit early and with a sensible error if unable to gain a write lock on the database. However, it has the major disadavantage that readers are excluded from the database for the entire time the command is running. +We are trying to monotone bailing when a transaction involving writes is committed. `BEGIN EXCLUSIVE` guarantees that monotone will exit early and with a sensible error if unable to gain a write lock on the database. However, it has the major disadavantage that readers are excluded from the database for the entire time the command is running. -Sqlite3 has several levels of locking. Some discussion has occurred of switching to "BEGIN IMMEDIATE" rather than "BEGIN EXLUSIVE"; only one process can hold an IMMEDIATE lock but SHARED (reader) access is still permitted. At the time of commit, IMMEDIATE transitions to PENDING (no new readers) to EXCLUSIVE. The amount of time readers are unable to access the DB is reduced, however we still encounter the crash if there is a reader in the db (see use case from NJS below). +Sqlite3 has several levels of locking. Some discussion has occurred of switching to `BEGIN IMMEDIATE` rather than `BEGIN EXLUSIVE`; only one process can hold an *IMMEDIATE* lock but *SHARED* (reader) access is still permitted. At the time of commit, *IMMEDIATE* transitions to *PENDING* (no new readers) to EXCLUSIVE. The amount of time readers are unable to access the DB is reduced, however we still encounter the crash if there is a reader in the db (see use case from [[NJS|people/NathanielSmith]] below). -Sqlite does save us from "dirty" reads; a dirty read is seeing uncommitted writes in another transaction. +Sqlite does save us from *dirty* reads; a dirty read is seeing uncommitted writes in another transaction. + # Use cases - * (from njs) e.g., "monotone diff | less monotone commit" -> crash, db is locked - * [[ViewMTN]] calls monotone a lot, only to do reads. It can't access the db when the database is being updated with "monotone pull". + * (from [[njs|people/NathanielSmith]]) e.g., `monotone diff | less`, ``, `monotone commit` -> crash, db is locked + * [ViewMTN](http://grahame.angrygoats.net/moinmoin/ViewMTN) calls monotone a lot, only to do reads. It can't access the db when the database is being updated with `monotone pull`. + # Ways forward -15:22 <@njs> "In the current implementation, the RESERVED lock is also released, but that is not essential. Future versions of SQLite might provide a "CHECKPOINT" SQL command that will commit all changes made so far within a transaction but retain the RESERVED lock so that additional changes can be made without given any other process an opportunity to write." -15:22 <@njs> ^^ sounds like what we've been wanting... + 15:22 <@njs> "In the current implementation, the RESERVED lock is also released, but that is not essential. Future versions of SQLite might provide a "CHECKPOINT" SQL command that will commit all changes made so far within a transaction but retain the RESERVED lock so that additional changes can be made without given any other process an opportunity to write." + 15:22 <@njs> ^^ sounds like what we've been wanting... Reference: + + * + * + * - * http://www.sqlite.org/lang_transaction.html - * http://www.sqlite.org/lockingv3.html - * http://www.postgresql.org/docs/8.1/static/transaction-iso.html