# # # rename "wiki/AlternativeOverview.moin" # to "wiki/AlternativeOverview.mdwn" # # rename "wiki/BuildBot/Windows.moin" # to "wiki/BuildBot/Windows.mdwn" # # rename "wiki/ConflictFixupPolicy.moin" # to "wiki/ConflictFixupPolicy.mdwn" # # rename "wiki/CustomCerts.moin" # to "wiki/CustomCerts.mdwn" # # rename "wiki/CvsSyncHints.moin" # to "wiki/CvsSyncHints.mdwn" # # rename "wiki/DifferentDbsForServeAndWork.moin" # to "wiki/DifferentDbsForServeAndWork.mdwn" # # rename "wiki/DocTodo.moin" # to "wiki/DocTodo.mdwn" # # rename "wiki/FAQ.moin" # to "wiki/FAQ.mdwn" # # rename "wiki/MasterRepository.moin" # to "wiki/MasterRepository.mdwn" # # rename "wiki/NeedReview.moin" # to "wiki/NeedReview.mdwn" # # rename "wiki/NetsyncTodo.moin" # to "wiki/NetsyncTodo.mdwn" # # rename "wiki/PathUI.moin" # to "wiki/PathUI.mdwn" # # rename "wiki/ReferenceCard.moin" # to "wiki/ReferenceCard.mdwn" # # rename "wiki/RoadMap.moin" # to "wiki/RoadMap.mdwn" # # rename "wiki/RootDirRenaming.moin" # to "wiki/RootDirRenaming.mdwn" # # rename "wiki/SpeedySpeedySHA1.moin" # to "wiki/SpeedySpeedySHA1.mdwn" # # rename "wiki/TestHarnessUseCases.moin" # to "wiki/TestHarnessUseCases.mdwn" # # rename "wiki/ThingsStatusShouldShow.moin" # to "wiki/ThingsStatusShouldShow.mdwn" # # rename "wiki/TipsTricksScripts.moin" # to "wiki/TipsTricksScripts.mdwn" # # rename "wiki/WishList.moin" # to "wiki/WishList.mdwn" # # patch "wiki/AlternativeOverview.mdwn" # from [64298e9c5aeb12bbee55bec06d77be7fa1706187] # to [527af6d692dfc2fc3eb9a05a52c612c52e56eec3] # # patch "wiki/BuildBot/Windows.mdwn" # from [540eb80ccc7743b48e09b488e2afa6a5264529c5] # to [1f5aa2dc0d014249ff6e0e78f07fd0e4bb449559] # # patch "wiki/ConflictFixupPolicy.mdwn" # from [5ccc7f40a0a9188cff825cbed785cec86857e364] # to [2203ef412e97bb21fc2cb29e9ecbab89d324c670] # # patch "wiki/CustomCerts.mdwn" # from [d3f2c1c70f15d6102d27a9629293608f07902fb5] # to [89345c4c1bd7a18149acde2211556076e8f18a57] # # patch "wiki/CvsSyncHints.mdwn" # from [615c4a769e44405571e727d40a9f91d60e191b9b] # to [e69700006fca12dd1da4a4c7e954a70db5d190c1] # # patch "wiki/DifferentDbsForServeAndWork.mdwn" # from [331ac326bb6f307385df1a8943826d67449c57a9] # to [9b7768fd1bcc8ecb0fa73226fdd6b258171b7574] # # patch "wiki/DocTodo.mdwn" # from [7577c68c83761158010be727383a0a12ddc9b034] # to [88763ceb57e0b89c473abacc7e1d340ca2e233a0] # # patch "wiki/FAQ.mdwn" # from [af93f15df3eda9503bf7a9cb2aafc6d9c3bbb69f] # to [72fdba50c17604ffdb84612c66235fc6bba0df65] # # patch "wiki/MasterRepository.mdwn" # from [94d9684b759d20a7fcfbddf11bff90a9a323bbbc] # to [dc92fc19c209321301f4b0f301bf48a55ed964e7] # # patch "wiki/NeedReview.mdwn" # from [158c8002ac2ca6897137322bc1bb398d56bab980] # to [f1136ce9621aba7094312d6c299fb180929685c8] # # patch "wiki/NetsyncTodo.mdwn" # from [61b2da91a2cce50a6c334eb2c5563b5e28d95570] # to [2aa155e140843c5e6682ace11ec6a55063bf0c22] # # patch "wiki/PathUI.mdwn" # from [e31e427d80b61c6146fd797f0961ee646d1806d3] # to [3c85c7d1ed5c07e07294ea68722df2fbe81a3adf] # # patch "wiki/ReferenceCard.mdwn" # from [27c20f68f0afe149e820051d4e245c50740fa7b2] # to [8eabb57e91e3aa5a738b991ee04264f6e0eb903b] # # patch "wiki/RoadMap.mdwn" # from [3447ec0bac245b5bf02e091431261fb57a564480] # to [4c332cd19ef0c4ce2a6005ee54f515539b0cde98] # # patch "wiki/RootDirRenaming.mdwn" # from [552c48fffb292782ac0c6c349fe2de73c1df7af7] # to [4a65605d808d4707174b50609c35fb31df0b6fb8] # # patch "wiki/SpeedySpeedySHA1.mdwn" # from [74a27e7945604bed19c1903c5d1d15be501552cc] # to [5cd0afa39d5049c12ce9c5255d35f3cfebdfda20] # # patch "wiki/TestHarnessUseCases.mdwn" # from [2ab96b3a8d76346d2dd452319fce4e14455bb690] # to [0742f9b49266074e3fb2e1f7ad5d40393181df16] # # patch "wiki/ThingsStatusShouldShow.mdwn" # from [e41153911464e829bf824d87f4386d3fe6d4cbc4] # to [d00fc6eec6935d8b05030ca469b483b7bfc7df50] # # patch "wiki/TipsTricksScripts.mdwn" # from [f00b50558d9c0e8440a20af52615c34edb93452e] # to [70eda9f9121aa26cc4d2a47d15711af9c2934872] # # patch "wiki/WishList.mdwn" # from [16675af8512ab789c5aae0990a95cde540dab065] # to [a30d547ba5925639d727c23d4004c45c546edd29] # ============================================================ --- wiki/AlternativeOverview.moin 64298e9c5aeb12bbee55bec06d77be7fa1706187 +++ wiki/AlternativeOverview.mdwn 527af6d692dfc2fc3eb9a05a52c612c52e56eec3 @@ -1,74 +1,77 @@ -''(Though there is a [http://venge.net/monotone/docs/index.html Monotone manual], 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 [http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone Wikipedia article].)'' +[[tag migration-auto]] -== P2P Database Basics == +*(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).)* -Monotone is a command-line utility which runs on many platforms, and is used to create and manage '''monotone databases'''. At a basic level, each ''monotone database'' can be thought of as storing archives of documents in directories on a file system. In this way of thinking, it is like a collection of ".zip" or ".tar" files. -=== Archiving === +## P2P Database Basics -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)''' +Monotone is a command-line utility which runs on many platforms, and is used to create and manage **monotone databases**. At a basic level, each *monotone database* can be thought of as storing archives of documents in directories on a file system. In this way of thinking, it is like a collection of ".zip" or ".tar" files. -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). +### Archiving -=== Extracting === +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)''' -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''. +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 === +### 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. +*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. -(NOTE: Technically, both the client and server could run on the same machine, allowing one ''monotone database'' to be updated from another ''monotone database'' on the same file system.) +(NOTE: Technically, both the client and server could run on the same machine, allowing one *monotone database* to be updated from another *monotone database* on the same file system.) -Once foreign ''revisions'' have been migrated into a ''monotone database'', you may ''checkout'' or ''update'' them to unpack snapshots of the files tracked by that revision. There is no need to be connected to the network to perform these ''checkouts'' and ''updates'', so long as the ''push'' or ''pull'' that moved the ''revision'' has been completed. +Once foreign *revisions* have been migrated into a *monotone database*, you may *checkout* or *update* them to unpack snapshots of the files tracked by that revision. There is no need to be connected to the network to perform these *checkouts* and *updates*, so long as the *push* or *pull* that moved the *revision* has been completed. -The term '''sync''' refers to a command that ''pushes'' and ''pulls'' at the same time. It is slightly faster than performing the two in succession. ''Sync'' has the advantage of utilizing your up and down bandwidth simultaneously. (The implementations of ''push'' and ''pull'' are built upon a core ''sync'' routine, but in those cases one side skips out on actually sending anything.) +The term **sync** refers to a command that *pushes* and *pulls* at the same time. It is slightly faster than performing the two in succession. *Sync* has the advantage of utilizing your up and down bandwidth simultaneously. (The implementations of *push* and *pull* are built upon a core *sync* routine, but in those cases one side skips out on actually sending anything.) -Because a ''monotone database'' is actually a [http://sqlite.org Sqlite database], it is a single file that is binary compatible across machine architectures. A ''monotone database'' usually starts out empty and is filled using ''commits'' and ''pulls''. However, copying a pre-prepared ''monotone database'' that someone else has populated may be faster than running the push/pull commands yourself. +Because a *monotone database* is actually a [Sqlite database](http://sqlite.org), it is a single file that is binary compatible across machine architectures. A *monotone database* usually starts out empty and is filled using *commits* and *pulls*. However, copying a pre-prepared *monotone database* that someone else has populated may be faster than running the push/pull commands yourself. -=== Labeling === +### Labeling -Security and network authorization in Monotone client/server relationships are managed by the use of cryptographic keys. It is also possible to add metadata onto individual ''revisions'' which is digitally signed, and this metadata is called a '''cert'''. Contributors may add as many of these signed ''certs'' as they like. Once a ''cert'' has been added it is not generally practical to remove it. +Security and network authorization in Monotone client/server relationships are managed by the use of cryptographic keys. It is also possible to add metadata onto individual *revisions* which is digitally signed, and this metadata is called a **cert**. Contributors may add as many of these signed *certs* as they like. Once a *cert* has been added it is not generally practical to remove it. -== Versioning in Monotone == +## 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 === +### Hierarchy -During a ''commit'', a relationship is generally set up between a ''"child" revision'' (the new one being created) and a ''"parent" revision'' (that already existed in the ''monotone database''). If a ''commit'' is run and a ''parent'' is indicated which already has a ''child'', then the ''parent'' will have multiple ''child'' ''revisions''. +During a *commit*, a relationship is generally set up between a *"child" revision* (the new one being created) and a *"parent" revision* (that already existed in the *monotone database*). If a *commit* is run and a *parent* is indicated which already has a *child*, then the *parent* will have multiple *child* *revisions*. -These relationships enable commands like "get the next/previous ''revision''", as opposed to making the user keep their own list of ''revision IDs''. When a ''commit'' is executed, it is assumed that the ''parent'' is the ''revision'' that was last fetched from the database via ''checkout'' or ''update''. If no ''checkout'' or ''update'' has been run since the last ''setup'' or ''commit'', it is assumed that the parent of the new version is the product of the prior ''setup'' or ''commit''. +These relationships enable commands like "get the next/previous *revision*", as opposed to making the user keep their own list of *revision IDs*. When a *commit* is executed, it is assumed that the *parent* is the *revision* that was last fetched from the database via *checkout* or *update*. If no *checkout* or *update* has been run since the last *setup* or *commit*, it is assumed that the parent of the new version is the product of the prior *setup* or *commit*. -(NOTE: For efficiency of implementation, Monotone uses ancestral relationships as a hint for how to store ''revisions'' efficiently. It is assumed that a ''parent'' and ''child'' will have a large amount in common and thus the database can store a "diff" instead of full copies of the changed files.) +(NOTE: For efficiency of implementation, Monotone uses ancestral relationships as a hint for how to store *revisions* efficiently. It is assumed that a *parent* and *child* will have a large amount in common and thus the database can store a "diff" instead of full copies of the changed files.) -=== Merging === +### Merging -Often it's the case that users on different machines will be adding independent ''children'' to a ''revision'' which they both ''pulled'' from a common source. When these two ''children'' are brought together into the same database, it will be apparent that there is a ''parent'' with multiple ''children''. The existence of this fork in the ancestry is a clue suggesting an intention to '''merge''' together these ''revisions'' as soon as possible. When a ''merge'' command is issued between two ''revisions'', the resulting ''revision'' is a child of both--which ties up a "stray" leaf in the ancestry graph. +Often it's the case that users on different machines will be adding independent *children* to a *revision* which they both *pulled* from a common source. When these two *children* are brought together into the same database, it will be apparent that there is a *parent* with multiple *children*. The existence of this fork in the ancestry is a clue suggesting an intention to **merge** together these *revisions* as soon as possible. When a *merge* command is issued between two *revisions*, the resulting *revision* is a child of both--which ties up a "stray" leaf in the ancestry graph. -The large ''revision id'' number which is generated to identify a ''revision'' (generated by either a ''commit'' or a ''merge'') is the product of a [http://en.wikipedia.org/wiki/Cryptographic_hash_function cryptographic function] of the file contents and the ancestry information. In terms of security, this means there's a strong assurance that any time someone mentions a ''revision id'' it can be verified as referring to the same data that the original speaker intended. Another consequence of naming ''revisions'' this way is that there are no conflicts at all if two users perform a ''merge'' or ''commit'' that generates identical results. They can ''push'' those identical ''revisions'' into a common ''monotone database'' without incident. +The large *revision id* number which is generated to identify a *revision* (generated by either a *commit* or a *merge*) is the product of a [cryptographic function](http://en.wikipedia.org/wiki/Cryptographic\_hash\_function) of the file contents and the ancestry information. In terms of security, this means there's a strong assurance that any time someone mentions a *revision id* it can be verified as referring to the same data that the original speaker intended. Another consequence of naming *revisions* this way is that there are no conflicts at all if two users perform a *merge* or *commit* that generates identical results. They can *push* those identical *revisions* into a common *monotone database* without incident. -As part of its operation, the ''update'' command will ''merge'' a ''revision'' into your current state, in those cases where you have not ''committed'' a ''revision'' for your local changes yet. This has the disadvantage of making it impossible to return '''(eds: your workspace)''' to the state prior to the ''update''. It is almost always more valuable to first ''commit'' your working changes, '''(eds: do the merge)''' and then ''update'' them '''(eds: them -> your workspace)'''. This provides a ''revision id'' that refers to your changes prior to merging, allowing you to extract or ''push'' your local changes if you needed to. +As part of its operation, the *update* command will *merge* a *revision* into your current state, in those cases where you have not *committed* a *revision* for your local changes yet. This has the disadvantage of making it impossible to return **(eds: your workspace)** to the state prior to the *update*. It is almost always more valuable to first *commit* your working changes, **(eds: do the merge)** and then *update* them **(eds: them -> your workspace)**. This provides a *revision id* that refers to your changes prior to merging, allowing you to extract or *push* your local changes if you needed to. -=== Branches === +### Branches -One of the widespread uses of ''certs'' in Monotone is to provide a textual label known as a '''branch'''. By convention, branches are given names that are hierarchical, in order to facilitate the use of wildcard pattern matching. The ''push'' and ''pull'' commands tend to use these wildcards, and are a way of saying "''push'' or ''pull'' all the ''revisions'' which match this wildcard". The creation of a named ''branch'' is usually a way of expressing a temporary (or permanent) intention to create code that's not to be merged into the "mainline" of a project. This is especially useful for indicating ''revisions'' that are part of a parallel development of new, tricky, or disruptive code. +One of the widespread uses of *certs* in Monotone is to provide a textual label known as a **branch**. By convention, branches are given names that are hierarchical, in order to facilitate the use of wildcard pattern matching. The *push* and *pull* commands tend to use these wildcards, and are a way of saying "*push* or *pull* all the *revisions* which match this wildcard". The creation of a named *branch* is usually a way of expressing a temporary (or permanent) intention to create code that's not to be merged into the "mainline" of a project. This is especially useful for indicating *revisions* that are part of a parallel development of new, tricky, or disruptive code. -Many of the monotone command-line parameters do not act specifically on ''revision ids'' but instead derive the relevant ids by querying for ''branch'' labels. There are benefits of using ''branch'' information which builds upon the ''cert'' system as opposed to raw ''revision id''s. The ''cert'' of a branch ensures that claims about a ''revision'' being the "latest" or the "most interesting one everyone should merge" can be tested cryptographically. (The commands don't happen to check these at the time of a ''pull'', but rather when a ''merge'' or ''checkout'' is being run.) +Many of the monotone command-line parameters do not act specifically on *revision ids* but instead derive the relevant ids by querying for *branch* labels. There are benefits of using *branch* information which builds upon the *cert* system as opposed to raw *revision id*s. The *cert* of a branch ensures that claims about a *revision* being the "latest" or the "most interesting one everyone should merge" can be tested cryptographically. (The commands don't happen to check these at the time of a *pull*, but rather when a *merge* or *checkout* is being run.) -One of the useful commands that can be run on a ''branch'' is to list its '''heads'''. These are the ''revisions'' that do not have any ''children'', which represent continuing independent paths of development within that ''branch''. Because branches are implemented using ''cert''s (and a ''cert'' can be put on any ''revision'') it is possible to label arbitrary ''revisions'' in the history as belonging to a ''branch''--giving it a new ''head''. These ''heads'' are typically ''merged'' together in a ''branch'', and they can be ''merged'' across ''branches'' using the '''propagate''' command. +One of the useful commands that can be run on a *branch* is to list its **heads**. These are the *revisions* that do not have any *children*, which represent continuing independent paths of development within that *branch*. Because branches are implemented using *cert*s (and a *cert* can be put on any *revision*) it is possible to label arbitrary *revisions* in the history as belonging to a *branch*--giving it a new *head*. These *heads* are typically *merged* together in a *branch*, and they can be *merged* across *branches* using the **propagate** command. -=== Histories === +### Histories -Currently, trying to ''push'' or ''pull'' a specific ''revision'' across ''monotone databases'' will also ''push'' or ''pull'' all ''revisions'' in its ancestry. This means that if you intend to join an existing project with considerable history, you won't be able to ''pull'' only the last few ''revisions''. There is no underlying technical reason why this needs to be the case, although there may be some implication in terms of the ability to verify the legitimacy of the cryptographic hashes if one is allowed to ''pull'' partial histories. +Currently, trying to *push* or *pull* a specific *revision* across *monotone databases* will also *push* or *pull* all *revisions* in its ancestry. This means that if you intend to join an existing project with considerable history, you won't be able to *pull* only the last few *revisions*. There is no underlying technical reason why this needs to be the case, although there may be some implication in terms of the ability to verify the legitimacy of the cryptographic hashes if one is allowed to *pull* partial histories. -A side effect of making frequent ''commits'' instead of using ''update'' is that this will create ''revisions'' that others are unlikely to be interested in, and which you may not wish to share. To keep from ''pushing'' these intermediate changes along when you ''push'' your final ''revision'' to others when they ''merge'', you can execute this procedure: +A side effect of making frequent *commits* instead of using *update* is that this will create *revisions* that others are unlikely to be interested in, and which you may not wish to share. To keep from *pushing* these intermediate changes along when you *push* your final *revision* to others when they *merge*, you can execute this procedure: - * monotone diff -r starting_base_revision > /tmp/mydiff + * monotone diff -r starting\_base\_revision > /tmp/mydiff * checkout the base again @@ -78,4 +81,4 @@ A side effect of making frequent ''commi '''(eds: this set of actions still doesn't make sense to me. i'm also not convinced that you should, as a practice, try to hide intermediate commits in this way. if you're primarily concerned about others trying to merge your commits too soon, just don't push until you are ready.)''' +This makes *revisions* an acceptable way of tracing more minute changes to files, such as to *commit* many times during editing. -This makes ''revisions'' an acceptable way of tracing more minute changes to files, such as to ''commit'' many times during editing. ============================================================ --- wiki/BuildBot/Windows.moin 540eb80ccc7743b48e09b488e2afa6a5264529c5 +++ wiki/BuildBot/Windows.mdwn 1f5aa2dc0d014249ff6e0e78f07fd0e4bb449559 @@ -1,27 +1,30 @@ -= Setting up a Buildslave for Monotone on Windows = +[[tag migration-auto]] -Here we explain how to run a buildbot on Win32 MinGW and Cygwin. +# Setting up a Buildslave for Monotone on Windows + +Here we explain how to run a buildbot on Win32 [[MinGW]] and Cygwin. + The buildbot code is written in Python, so we need a Python -implementation. Ideally, we would use a MinGW Python implementation -for the MinGW buildbot, and a Cygwin one for the Cygwin buildbot. +implementation. Ideally, we would use a [[MinGW]] Python implementation +for the [[MinGW]] buildbot, and a Cygwin one for the Cygwin buildbot. There is a Cygwin Python. It has some trouble during installation, but it does work for the buildbot. -There is no MinGW Python. There is a native Win32 Python, but it uses -"cmd.exe" to run shell commands; we want it to use MinGW bash. +There is no [[MinGW]] Python. There is a native Win32 Python, but it uses +"cmd.exe" to run shell commands; we want it to use [[MinGW]] bash. Fortunately, there is a workaround for this (see below); we can use -the Cygwin Python buildbot to run MinGW bash scripts. +the Cygwin Python buildbot to run [[MinGW]] bash scripts. -We assume the tools required to build monotone on MinGW are installed; -see BuildOnWindows. +We assume the tools required to build monotone on [[MinGW]] are installed; +see [[BuildOnWindows]]. -== Install Cygwin == +## Install Cygwin 1. Download the Cygwin installer from http://cygwin.com/, and run it - 1. Install to "C:/", ''not'' the default "C:/Cygwin". The Cygwin installer says this is not a good idea; ignore that. + 1. Install to "C:/", *not* the default "C:/Cygwin". The Cygwin installer says this is not a good idea; ignore that. The reason we do this is to make Windows file syntax match Cygwin syntax on the C drive. Installing to "C:/" means Cygwin mounts "C:/" as "/", so Cygwin paths on the C drive are "/..." rather @@ -29,7 +32,7 @@ see BuildOnWindows. It may be possible to make the buildbot work with Cygwin installed at "C:/Cygwin"; I have not tried it. - Note that MinGW is ''not'' installed at "C:/"; that would collide with Cygwin. This means bash scripts run by MinGW must use MinGW file syntax: "/c/...". + Note that [[MinGW]] is *not* installed at "C:/"; that would collide with Cygwin. This means bash scripts run by [[MinGW]] must use [[MinGW]] file syntax: "/c/...". 1. Include the following packages: * Devel/autoconf @@ -46,18 +49,18 @@ see BuildOnWindows. cvs and inetutils are required by autoconf, but are not included in the Cygwin installer dependency lists. -== Install released MinGW monotone == +## Install released [[MinGW]] monotone -We need a working monotone to pull the monotone source from the server. You can use either the Cygwin monotone, or the released MinGW monotone. In either case, the buildbot master needs to know where the working monotone is. It can be in PATH for the user that runs the buildbot. +We need a working monotone to pull the monotone source from the server. You can use either the Cygwin monotone, or the released [[MinGW]] monotone. In either case, the buildbot master needs to know where the working monotone is. It can be in PATH for the user that runs the buildbot. -== Install buildbot == +## Install buildbot We use /Apps as the source area; use another path if it suites you. 1. Download zope.interface-3.3.0.tar.gz from http://zope.org/Products/ZopeInterface/ - 1. Download Twisted 2.5 source (''not'' the Win32 installer) from http://twistedmatrix.com/trac/. The file name is Twisted-2.5.0.tar.bz2 + 1. Download Twisted 2.5 source (*not* the Win32 installer) from http://twistedmatrix.com/trac/. The file name is Twisted-2.5.0.tar.bz2 - 1. Download BuildBot sources as patched for monotone from http://guardian.lp.se/debian/testing/. The file name is buildbot_0.7.5-1.1+RL20070709-2testing.tar.gz + 1. Download [[BuildBot]] sources as patched for monotone from http://guardian.lp.se/debian/testing/. The file name is buildbot_0.7.5-1.1+RL20070709-2testing.tar.gz 1. Install zope: 1. {{{ @@ -77,7 +80,7 @@ python ./setup.py install }}} 1. Install Twisted. - It has similar link problems, and 'runner' fails entirely, because it needs 'pmap_set', which should be in libc.a, but isn't on Cygwin. Fortunately, we don't need 'runner'. + It has similar link problems, and 'runner' fails entirely, because it needs 'pmap\_set', which should be in libc.a, but isn't on Cygwin. Fortunately, we don't need 'runner'. 1. {{{ cd /Apps @@ -93,7 +96,7 @@ python ./setup.py install This encounters similar link problems as above 1. {{{ -cd TwistedCore-2.5.0 +cd [[TwistedCore]]-2.5.0 link manually cd .. python ./setup.py install @@ -108,17 +111,17 @@ python ./setup.py install python ./setup.py install }}} -== Setup buildbot for MinGW == +## Setup buildbot for [[MinGW]] If desired for security, create a user account to run the buildbot. The buildbot runs code downloaded from the monotone buildbot server; there is a chance that will be hacked, or that the code is broken, and might do something harmful. It may also be helpful to have separate user for the buildbot, in order to set PATH properly. -We create local scripts to run the monotone build commands in an Msys shell, because that's the only way to get a PATH that has only MinGW in it. +We create local scripts to run the monotone build commands in an Msys shell, because that's the only way to get a PATH that has only [[MinGW]] in it. - 1. Set PATH for the user running buildbot to include Cygwin, but ''not'' MinGW. It may include the MinGW monotone, but that's not required. + 1. Set PATH for the user running buildbot to include Cygwin, but *not* [[MinGW]]. It may include the [[MinGW]] monotone, but that's not required. - 1. Ask on the monotone mail list http://mail.nongnu.org/mailman/listinfo/monotone-devel for a bot name and password. In the message, include the path for running the working monotone. If it is in PATH, just say "mtn". Also be sure to say you are running a MinGW buildbot; it needs the buildbot master that uses local scripts to run commands. + 1. Ask on the monotone mail list http://mail.nongnu.org/mailman/listinfo/monotone-devel for a bot name and password. In the message, include the path for running the working monotone. If it is in PATH, just say "mtn". Also be sure to say you are running a [[MinGW]] buildbot; it needs the buildbot master that uses local scripts to run commands. Richard Levitte handles the buildbot master setup. 1. Create a directory that will contain the buildbot scripts and the monotone source and build directory. It must be writeable by the user running the buildbot. Here we'll call this "/Gnu/monotone-buildbot-mingw" @@ -132,7 +135,7 @@ cp /Apps/MinGW/bin/gcc.exe /Apps/MinGW/b cp /Apps/MinGW/bin/gcc.exe /Apps/MinGW/bin/cc.exe }}} - 1. Create local shell scripts to run MinGW commands from Cygwin Python buildbot. Adjust the paths to match your setup. Note the MinGW syntax in some of the paths. + 1. Create local shell scripts to run [[MinGW]] commands from Cygwin Python buildbot. Adjust the paths to match your setup. Note the [[MinGW]] syntax in some of the paths. 1. autoreconf-local.sh {{{ /MinGW/bin/sh.exe --login -c /c/Gnu/monotone-buildbot-mingw/autoreconf.sh @@ -176,9 +179,9 @@ buildbot start /Gnu/monotone-buildbot-mi The first time it runs, it does some more setup. It logs everything to /Gnu/monotone-buildbot-mingw/twistd.log -== Setup Cygwin buildbot == +## Setup Cygwin buildbot -A Cygwin buildbot uses the same Twisted installation as a MinGW buildbot. +A Cygwin buildbot uses the same Twisted installation as a [[MinGW]] buildbot. Because Cygwin is very similar to Unix, we can use the standard buildbot master scripts; no need for local scripts. @@ -188,7 +191,7 @@ ln --symbolic /usr/include/boost-1_33_1/ ln --symbolic /usr/include/boost-1_33_1/boost /usr/include/boost }}} -== Running the Buildslave == +## Running the Buildslave There are several ways to run a buildslave. If the Windows box is a dedicated buildbot machine, the simplest is to just run it from a Cygwin bash shell each time you reboot the box: ============================================================ --- wiki/ConflictFixupPolicy.moin 5ccc7f40a0a9188cff825cbed785cec86857e364 +++ wiki/ConflictFixupPolicy.mdwn 2203ef412e97bb21fc2cb29e9ecbab89d324c670 @@ -1,8 +1,11 @@ -This is about what we do during MergeViaWorkingDir or WorkspaceConflicts in order to turn the "insane" (technical term) roster into a "sane" one so we can actually write it out. This is not a resolution to the conflict! This is only the mechanical, least-effort repair that lets us get out to where we can take user interaction. +[[tag migration-auto]] + +This is about what we do during [[MergeViaWorkingDir]] or [[WorkspaceConflicts]] in order to turn the "insane" (technical term) roster into a "sane" one so we can actually write it out. This is not a resolution to the conflict! This is only the mechanical, least-effort repair that lets us get out to where we can take user interaction. + There are seven kinds of conflicts that roster merge can produce: each is a subsection below. -== node_name_conflict == +## node\_name\_conflict Attach somewhere, i.e. make up a name that we know does not exist (because we checked) @@ -12,38 +15,38 @@ Record name in left, right + right: parent name and basename -== file_content_conflict == +## file\_content\_conflict make up some content (with <<<< in) "add" left, right, "L"CA tempfiles -== node_attr_conflict == +## node\_attr\_conflict need: key, value on left; value on right -== orphaned_node_conflict == +## orphaned\_node\_conflict make up name, maybe in a subdir, attach it record old name / parent -== rename_target_conflict == +## rename\_target\_conflict attach both somewhere want to know what the old name(s) were -== directory_loop_conflict == +## directory\_loop\_conflict this occurs from two directories a and b by renaming a to b/a on one side, b to a/b on the other attach somewhere -== illegal_name_conflict == +## illegal\_name\_conflict attach somewhere -== missing_root_dir == +## missing\_root\_dir create one ============================================================ --- wiki/CustomCerts.moin d3f2c1c70f15d6102d27a9629293608f07902fb5 +++ wiki/CustomCerts.mdwn 89345c4c1bd7a18149acde2211556076e8f18a57 @@ -1,5 +1,9 @@ -Monotone uses some common certs according to standard conventions as described in UsingCerts, but this is just a start. +[[tag migration-auto]] + +Monotone uses some common certs according to standard conventions as described in [[UsingCerts]], but this is just a start. + Certs are intended as an extendable way to store metadata about revisions. Some people even use them for this! Here are some interesting uses I know about: + * Xaraya uses them to track branch descriptions and status -- latest cert on a branch wins. http://mt.xaraya.com/com.xaraya.core/index.psp * bug fixes and shipping to clients: http://article.gmane.org/gmane.comp.version-control.monotone.devel/6476 (not clear if these examples are real or made up?) ============================================================ --- wiki/CvsSyncHints.moin 615c4a769e44405571e727d40a9f91d60e191b9b +++ wiki/CvsSyncHints.mdwn e69700006fca12dd1da4a4c7e954a70db5d190c1 @@ -1,7 +1,10 @@ -The cvs_sync branch is an experimental facility to help users work with ["MonotoneAndCVS"] +[[tag migration-auto]] -For the newest rewrite see CvsSync3. +The cvs\_sync branch is an experimental facility to help users work with ["[[MonotoneAndCVS]]"] + +For the newest rewrite see [[CvsSync3]]. + You may want to not stress cvssync to the full extent. It definitely has problems when the time jumps (no I mean not summer vs. winter time) because then the simplistic and easy to use map which sorts revisions by @@ -11,7 +14,7 @@ killer]. lifetime and constructing diffs between old revisions of a file is a killer]. -Try cvs_takeover (an ''unmodified'' tree saves you worries elsewhere! *) +Try cvs\_takeover (an *unmodified* tree saves you worries elsewhere! *) and continue to work from there. Merging, updating, committing etc. really work nice and the server is not charged that much this way. Most people (including me) do not need full history. @@ -24,9 +27,10 @@ If anything goes terribly wrong the most server. If anything goes terribly wrong the most efficient way to resync is: + * check the module with CVS out into an empty directory * change into that directory - * monotone --db foo.db --branch foobranch cvs_takeover [foomodule] + * monotone --db foo.db --branch foobranch cvs\_takeover [foomodule] * monotone merge *) cvssync inserts empty dummy files as the initial state which give a ============================================================ --- wiki/DifferentDbsForServeAndWork.moin 331ac326bb6f307385df1a8943826d67449c57a9 +++ wiki/DifferentDbsForServeAndWork.mdwn 9b7768fd1bcc8ecb0fa73226fdd6b258171b7574 @@ -1,3 +1,6 @@ +[[tag migration-auto]] + + At some point you'll want to share your work with others, and set up a sync server. You can run a 'mtn serve' off of the same database that you check all of your changes into. This will work, but it has problems: * when you are working, and commiting code, monotone locks the database. The monotone server then can't serve anything anymore. ============================================================ --- wiki/DocTodo.moin 7577c68c83761158010be727383a0a12ddc9b034 +++ wiki/DocTodo.mdwn 88763ceb57e0b89c473abacc7e1d340ca2e233a0 @@ -1,40 +1,43 @@ +[[tag migration-auto]] + + Some tasks for improvements to documents: -= problems = +# problems * reference docs for automate commands actually document the different tokens that can appear * automate.cc duplicates this reference stuff in comments -= user documentation = +# user documentation * improve the getting started entry points, perhaps into several different documents with stories told from different perspectives: * a quick worked-through example, with commands and output and very brief comments (links to more details) for a quick overview * someone getting started on a new, blank project (like juicebot) - * someone pulling down an existing monotone-hosted project (like monotone's [http://venge.net/monotone/self-hosting.html self-hosting] page; even a template for other projects to stick on their sites to help get users started, with links back to monotone doc for more details) + * someone pulling down an existing monotone-hosted project (like monotone's [self-hosting](http://venge.net/monotone/self-hosting.html) page; even a template for other projects to stick on their sites to help get users started, with links back to monotone doc for more details) * someone looking to migrate an existing project from other-VCS to monotone * someone looking to use multiple VCS's in parallel, perhaps while trialling them, via .cvssync or tailor * source-code tour (see http://opensolaris.org/os/community/zfs/source/ for a good example in another project) * ... ? - * A good writeup of similar ideas: http://headrush.typepad.com/creating_passionate_users/2006/09/how_to_get_user.html + * A good writeup of similar ideas: http://headrush.typepad.com/creating\_passionate\_users/2006/09/how\_to\_get\_user.html - * a "usage guide" document (or set of wiki pages, even) on common patterns, BestPractices, TipsTricksScripts, etc + * a "usage guide" document (or set of wiki pages, even) on common patterns, [[BestPractices]], [[TipsTricksScripts]], etc * why you should commit before update, why you should pull and merge before pushing, etc - * a good description of how to use branching and propagate; see savannah #6523 and possibly using the BranchAnalogy + * a good description of how to use branching and propagate; see savannah #6523 and possibly using the [[BranchAnalogy]] * njs (in particular) is constantly coming out with cool little shell snippets using "monotone list ..." and "monotone automate ..." commands. * generate the man page from commands.cc's metadata. (maybe simplest just to add a monotone command that dumps out some troff or something; run it during build.) -= advanced / internals documentation = +# advanced / internals documentation - * formally document the basic_io format, and its intentions and usages. a lot of the automate commmands will emit or consume this format, and an understanding of the precepts will be vital for advanced users and authors of additional tools using monotone. + * formally document the basic\_io format, and its intentions and usages. a lot of the automate commmands will emit or consume this format, and an understanding of the precepts will be vital for advanced users and authors of additional tools using monotone. * see http://lists.gnu.org/archive/html/monotone-devel/2005-10/msg00033.html for a beginning - * see BasicIoFormalisation for some details and debate + * see [[BasicIoFormalisation]] for some details and debate * a definition of the whitespace normalisation that goes on * a reference for the entitities that can be emitted (data type dictionary), either as a list or as a component of each command description - * see http://colabti.de/irclogger/irclogger_log/monotone?date=2005-11-25,Fri&sel=117#l194 for some more discussion + * see http://colabti.de/irclogger/irclogger\_log/monotone?date=2005-11-25,Fri&sel=117#l194 for some more discussion * netsync theory and operational model (less so the specific bitwise wire protocol) * how merging really works, and how to get specific results and fine-grained control over it, for advanced users * document and draw rosters + * document the merge algorithm we use (straight-forward adaptation of the [multi-*-merge paper](http://article.gmane.org/gmane.comp.version-control.revctrl/93) gives a start, plus things like lifecycle, attrs, etc.) -- very useful for advanced users, too. - * document the merge algorithm we use (straight-forward adaptation of the [http://article.gmane.org/gmane.comp.version-control.revctrl/93 multi-*-merge paper] gives a start, plus things like lifecycle, attrs, etc.) -- very useful for advanced users, too. ============================================================ --- wiki/FAQ.moin af93f15df3eda9503bf7a9cb2aafc6d9c3bbb69f +++ wiki/FAQ.mdwn 72fdba50c17604ffdb84612c66235fc6bba0df65 @@ -1,49 +1,55 @@ -= Where should I go to ask more questions? = +[[tag migration-auto]] + + +# Where should I go to ask more questions? + * on IRC: irc.oftc.net #monotone * via email: http://mail.nongnu.org/mailman/listinfo/monotone-devel -= What are these libraries monotone depends on? = -[http://www.boost.org/ Boost] +# What are these libraries monotone depends on? +[Boost](http://www.boost.org/) A set of general-purpose C++ libraries with lots of features. I use it for string processing (regexps, parsing), sockets, portable filename handling, and more. It's superb. Currently, that's all; and it is possible (and easy) to statically link against Boost, to create a binary usable on a system with no external libraries at all. -= Why did you use SHA1 as your hash algorithm? = +# Why did you use SHA1 as your hash algorithm? + * It's a secure hash: nobody can look at a cert on some SHA1 hash code and cook up a fake file with the same hash code (hijacking the cert) in any reasonable amount of time. * Of the secure hashes, it's among the most well known. * Of the well-known secure hashes, it's the one with the least number of rumors circulating about it having been broken; md4 is supposedly dead meat, and md5 has (some) people worried. * The speed problem -- SHA1 is a bit slow -- seems mostly overwhelmed by I/O and the time spent in RSA. The benchmark on SHA1 shows it doing over 40mb / sec on a celeron. It should be fast enough. -= But what about the rumors that SHA1 is broken? = -There are indeed such [http://www.schneier.com/blog/archives/2005/02/sha1_broken.html rumors]. We're watching closely, and if this is confirmed, we'll wait until the cryptographic community settles on a replacement, and switch to using that. We know how to do the switch, and it should be straightforward. +# But what about the rumors that SHA1 is broken? +There are indeed such [rumors](http://www.schneier.com/blog/archives/2005/02/sha1_broken.html). We're watching closely, and if this is confirmed, we'll wait until the cryptographic community settles on a replacement, and switch to using that. We know how to do the switch, and it should be straightforward. In the mean time, we can wait until consensus emerges before making the switch. The reported attacks are still extremely costly (it remains much, much easier to break into your computer and steal your key), and there are many, many applications just as vulnerable and far more interesting to attack (e.g., SSL host certificates, PGP keys, etc.). We'll fix it, when we can be confident that our fix is correct. -= How do you merge versions? = +# How do you merge versions? The merging system is based on a pair of 3-way merges: one set-oriented one at the changeset level to resolve differences in tree layout (file and directory renames, for instance), and one line-oriented one at the file level, to resolve differences in concurrent edits to the same file. If either of these fail, they are passed off to a user-provided hook function, which invokes emacs ediff mode by default (but can be overridden). -It is important to note that a 3-way merge is not the same as simply "applying patches" in one order or another: we locate the least common ancestor of the merged children in our ancestry graph, calculate the edits on the left and right edges, adjust the right edge's edit coordinates based on the left edge's edits, and only ''then'' do we concatenate the left and right edges (ignoring identical changes, and rejecting conflicting ones). +It is important to note that a 3-way merge is not the same as simply "applying patches" in one order or another: we locate the least common ancestor of the merged children in our ancestry graph, calculate the edits on the left and right edges, adjust the right edge's edit coordinates based on the left edge's edits, and only *then* do we concatenate the left and right edges (ignoring identical changes, and rejecting conflicting ones). -= Monotone wants me to use a merge tool; what do you recommend? = -The best we know for merging is [http://furius.ca/xxdiff/ xxdiff]. Just install it, and monotone will automatically default to using it for merges. +# Monotone wants me to use a merge tool; what do you recommend? +The best we know for merging is [xxdiff](http://furius.ca/xxdiff/). Just install it, and monotone will automatically default to using it for merges. -= Isn't it annoying that xxdiff doesn't have any keybinding for "save as merged"? = -`echo 'Accel.SaveAsMerged: "Ctrl+M"' >>~/.xxdiffrc` +# Isn't it annoying that xxdiff doesn't have any keybinding for "save as merged"? +`echo 'Accel.[[SaveAsMerged]]: "Ctrl+M"' >>~/.xxdiffrc` -= What is the "networking protocol"? = -The networking protocol is called `netsync`. It is a bi-directional pipelined protocol for synchronizing collections using a tree of hashed indices. It allows any copy of monotone to function as either a client or a server, and rapidly synchronize or half-synchronize (push / pull) their database with another user. It is somewhat similar in flavor to [http://samba.anu.edu.au/rsync/ rsync] or [http://www.cis.upenn.edu/~bcpierce/unison/ Unison], in that it quickly and idempotently synchronizes information across the network without needing to store any local state; however, it is much ''more'' efficient than these protocols. +# What is the "networking protocol"? +The networking protocol is called `netsync`. It is a bi-directional pipelined protocol for synchronizing collections using a tree of hashed indices. It allows any copy of monotone to function as either a client or a server, and rapidly synchronize or half-synchronize (push / pull) their database with another user. It is somewhat similar in flavor to [rsync](http://samba.anu.edu.au/rsync/) or [Unison](http://www.cis.upenn.edu/~bcpierce/unison/), in that it quickly and idempotently synchronizes information across the network without needing to store any local state; however, it is much *more* efficient than these protocols. -An important fact about monotone's networking is that it deals in ''facts'' rather than ''operations''. Networking simply ''informs'' the other party of some facts, and receives some facts from the other party. The netsync protocol determines which facts to send, based on an interactive analysis of "what is missing" on each end. No obligations, transactions, or commitments are made during networking. For all non-networking functions, monotone decides what to do by interpreting the ''facts'' it has on hand, rather than having specific conversations with other programs. Only the `push`, `pull`, `sync` and `serve` commands exchange data with anyone else on the network. The rest of the time, monotone is "offline". +An important fact about monotone's networking is that it deals in *facts* rather than *operations*. Networking simply *informs* the other party of some facts, and receives some facts from the other party. The netsync protocol determines which facts to send, based on an interactive analysis of "what is missing" on each end. No obligations, transactions, or commitments are made during networking. For all non-networking functions, monotone decides what to do by interpreting the *facts* it has on hand, rather than having specific conversations with other programs. Only the `push`, `pull`, `sync` and `serve` commands exchange data with anyone else on the network. The rest of the time, monotone is "offline". -= What happened to HTTP, NNTP, SMTP? = +# What happened to HTTP, NNTP, SMTP? Monotone used to support a variety of networking protocols. Now it only does netsync. This is because the older networking protocols were based on log replay, which inherently produced coupling between clients and servers. The netsync protocol always works out what to send and receive "on the fly". This is something which is not as easy to do -- especially not so efficiently -- over HTTP, NNTP and SMTP. -= What is the "server"? = +# What is the "server"? There is no separate server software. Each client can act as a server by running the `serve` command. When a client contacts a server, it can send and receive facts the server has not yet seen; these can be facts about the client, or facts about other peers. There is no coupling between each client or server, so if one server goes offline, any other client can take over the role of server for a group of users. This design follows the philosophy of "end-to-end" networking, putting the brains of the system in the clients, and relegating network communication to the role of exchanging "dumb" informative data packets. Each network exchange is stateless, and monotone does not rely on the identity, location or availability of a particular networking host between exchanges. Netsync exchanges can also be tunneled through SSH, so running a dedicated `mtn serve` process is not required. -= Why an embedded SQL database, instead of Berkeley DB? = +# Why an embedded SQL database, instead of Berkeley DB? + * There is a nice little command-line tool to manipulate databases by hand. You should never have to use it, but it is good to know it is there in emergencies. * Sqlite is actually smaller and simpler than Berkeley DB, as it has far fewer adjustable knobs and modes of operation. * SQL has a much richer data vocabulary built-in (tuples, uniqueness constraints, joins, indices, sorts, globs, unions, intersections, etc.) @@ -52,7 +58,7 @@ Netsync exchanges can also be tunneled t * The state of the database is one big SQL statement, which you can dump out and edit in vi. * It leaves the door open to retargeting monotone to a larger RDBMS without much effort, if it's attractive to do so someday in the future. (Though, it has become clear that SQLite performs excellently, and it isn't clear why this would be attractive; see below.) -= What about "real" SQL databases? Can I use monotone with PostgreSQL/MySQL/Oracle/...? = +# What about "real" SQL databases? Can I use monotone with [[PostgreSQL]]/MySQL/Oracle/...? Like many things, if you wrote code for this, it could be made to happen. However, it probably won't accomplish what you want. * Some people want this so they can let multiple people access the same repository at once. However, this will not work; monotone prohibits concurrent access to a single repo for reasons of simplicity, robustness, and confidence in correctness. We agree that it is occasionally annoying that access to the database is serialized (though less annoying than many people expect), so we would be very interested in a plan for how to permit it in a way that is both safe, and obviously safe. @@ -62,51 +68,52 @@ So, overall, there are no technical adva So, overall, there are no technical advantages to using a traditional RDBMS, and some compelling disadvantages -- and this is not even including the relative administrative costs of "a file" versus "a daemon, with its own access controls, administration, users, ...". -= Can monotone store binary files? = +# Can monotone store binary files? Yes. Monotone's internal delta storage format is byte-oriented: it is an implementation of Josh Mac''''''Donald's xdelta system. -= Can I convert CVS archives? = +# Can I convert CVS archives? Yes. Monotone can parse RCS `,v` files directly, synthesize the logical change history across a CVS repository, and import the results into a monotone database. No extra software is required. The conversion also converts branches, but does not connect them. This is being worked on. -= Why not use GNU diff format diffs with GPG signatures? = +# Why not use GNU diff format diffs with GPG signatures? + * Classical diffs don't do binary very well. * GPG as a subprocess is slow, tricky and fragile; using the botan crypto library in-process is fast, simple and reliable. * Classical diffs may be whitespace-mangled, which invalidates signatures, so you need to ascii-armor it anyways. - * OpenPGP packet format is quite baroque, we need much ''less'' than it can do. - * The web of trust is useful for verifying that the name on a key matches the name on a passport. It isn't very useful for verifying that the holder of a key should have commit access to your project. We like to trust keys based on the quality of the code they sign, not based on the name attached to them. (In fact, every VCS we know of that does use OpenPGP keys doesn't leverage the web of trust at all, but rather requires you to explicitly upload each key you want to trust.) + * [[OpenPGP]] packet format is quite baroque, we need much *less* than it can do. + * The web of trust is useful for verifying that the name on a key matches the name on a passport. It isn't very useful for verifying that the holder of a key should have commit access to your project. We like to trust keys based on the quality of the code they sign, not based on the name attached to them. (In fact, every VCS we know of that does use [[OpenPGP]] keys doesn't leverage the web of trust at all, but rather requires you to explicitly upload each key you want to trust.) * In the rare case where you do know that the person whose passport says "Jane Doe" is a hotshot coder who should definitely have commit access, you can always ask her to just PGP-sign her email saying "my monotone key's fingerprint is 70a0f283898a18815a83df37c902e5f1492e9aa2". * You likely don't want to use your real PGP key for developing software in any case; most PGP keys should not, for instance, be put on a laptop that might be stolen. Yet many people would like to develop software while using their laptops. -= Why don't you assign "version numbers" to files / trees, like "2.7"? = -We thought to do this at first. But after discussion it seemed that to assign such numbers uniquely, you are faced with needing either a common authority to appeal to, or a really large number-space in which you will likely not collide. Then we thought, well, in the case of the latter, why ''not'' just use a content hash? Then it became apparent that lots of nice things happen for free when you make that choice. So we stuck with it. +# Why don't you assign "version numbers" to files / trees, like "2.7"? +We thought to do this at first. But after discussion it seemed that to assign such numbers uniquely, you are faced with needing either a common authority to appeal to, or a really large number-space in which you will likely not collide. Then we thought, well, in the case of the latter, why *not* just use a content hash? Then it became apparent that lots of nice things happen for free when you make that choice. So we stuck with it. People still ask for version numbers, but we don't know of any way to assign them that gives unique, sensible identifiers to all revisions (remember that there's much more branching and merging in monotone than in, say, CVS), and that keeps these identifiers stable in a distributed environment (i.e., existing revisions don't get new numbers when you commit or sync), and that assigns numbers consistently (so I can use a version number when talking to you, and trust that it will mean the same thing to you that it does to me). -= Isn't there a paper that proves that SHA1 codes are no good for version identifiers? = -You probably mean [http://www.nmt.edu/~val/review/hash/index.html this paper]. +# Isn't there a paper that proves that SHA1 codes are no good for version identifiers? +You probably mean [this paper](http://www.nmt.edu/~val/review/hash/index.html). -We think that paper is wrong. We have written a more [http://www.venge.net/monotone/docs/Hash-Integrity.html detailed response] in the manual, if you would like to examine it for yourself. +We think that paper is wrong. We have written a more [detailed response](http://www.venge.net/monotone/docs/Hash-Integrity.html) in the manual, if you would like to examine it for yourself. -= How do I work in "lock step" with other users? = -You don't. Like CVS, monotone acknowledges that users work in parallel, and that the task of a version control system is to help ''manage'' the divergence caused by parallelism, not eliminate it. Unlike CVS, there is no such thing as a "central" monotone server, which tracks the unique head state of a branch. Each branch can have multiple "parallel" heads. +# How do I work in "lock step" with other users? +You don't. Like CVS, monotone acknowledges that users work in parallel, and that the task of a version control system is to help *manage* the divergence caused by parallelism, not eliminate it. Unlike CVS, there is no such thing as a "central" monotone server, which tracks the unique head state of a branch. Each branch can have multiple "parallel" heads. -= If I make a change in parallel with a colleague, what happens? = -You produce divergence. When you and your colleague exchange packets, you will find that the branch now has two heads, not one. One or other (or both) of you can then ''reduce'' the divergence by performing a merge. +# If I make a change in parallel with a colleague, what happens? +You produce divergence. When you and your colleague exchange packets, you will find that the branch now has two heads, not one. One or other (or both) of you can then *reduce* the divergence by performing a merge. -= If we both merge, doesn't that recreate divergence? = +# If we both merge, doesn't that recreate divergence? Maybe, but probably not. If you both do an automatic merge using the same algorithm (built into monotone) and arrive at the same merged tree state (identified by SHA1 -- a content hash), then there is no divergence anymore. -If one of you has to manually intervene in the merge, you will produce two new heads, but unless your intervention involved the ''entire'' merge, your two new heads will be ''closer together'' than the two heads you had going into the merge. You can try again on the next exchange. Nothing breaks when there are multiple heads. +If one of you has to manually intervene in the merge, you will produce two new heads, but unless your intervention involved the *entire* merge, your two new heads will be *closer together* than the two heads you had going into the merge. You can try again on the next exchange. Nothing breaks when there are multiple heads. -= Isn't multiple heads on a branch dangerous or crazy? = +# Isn't multiple heads on a branch dangerous or crazy? Not at all. CVS implicitly lets your entire team maintain multiple heads (in their working copies) all the time. Monotone just records the fact in the database, so it doesn't get "lost" in a clobbered or unavailable working copy. Here is an example: have you ever had a CVS working copy with an interesting change on your desktop, and wanted to move it to your laptop, or take it home for the evening to tinker with? Using CVS, the divergence is "hidden" from the CVS server until you commit, by which time it must be "resolved". Using monotone, you can commit whenever you like; you will just make a new head. You can check out that new head and continue to work on it (at home, on a laptop, wherever) until you're satisfied that it's OK, then merge with your colleagues. -Monotone takes the approach that divergence is a fundamental part of being a VCS. Divergence always happens. The proper role of a VCS, then, is not to try to prevent or hide divergence, but instead to make it ''visible'' and provide ''tools to manage it''. +Monotone takes the approach that divergence is a fundamental part of being a VCS. Divergence always happens. The proper role of a VCS, then, is not to try to prevent or hide divergence, but instead to make it *visible* and provide *tools to manage it*. -= How is that different from "lightweight branches"? = +# How is that different from "lightweight branches"? Not very different at all. Every time you commit, you may be making a fork in the storage system. In monotone's view, a branch is just a set of instructions about which forks you want to merge and which ones you want to remain not-merged. If you want your fork to remain not-merged with your colleagues, you put it on a different branch. That's all. +# Can you "cherry-pick" changes from one branch/version to another? +*Update:** Yes. Visit [[CherryPicking]] for information on the new **pluck*' command. -= Can you "cherry-pick" changes from one branch/version to another? = -''Update:''' Yes. Visit CherryPicking for information on the new '''pluck''' command. ============================================================ --- wiki/MasterRepository.moin 94d9684b759d20a7fcfbddf11bff90a9a323bbbc +++ wiki/MasterRepository.mdwn dc92fc19c209321301f4b0f301bf48a55ed964e7 @@ -1,14 +1,17 @@ -= Distributed VCS = +[[tag migration-auto]] + +# Distributed VCS + Monotone is a Distributed VCS. -== There is no Master... == +## There is no Master... Unlike other version control systems people may be accustomed to, especially centralised systems such as CVS and SVN, in monotone -''there is no "Master Repository" in any special privileged sense''. +*there is no "Master Repository" in any special privileged sense*. -== ... even though it might look like there is == +## ... even though it might look like there is It is certainly true that for many projects (including monotone itself) there's often a central server where a repository @@ -16,12 +19,12 @@ point of reference, and to avoid long re Developers `sync` with this server as an easy central point of reference, and to avoid long relay replication chains. -In the [http://venge.net/monotone/docs/Tutorial.html Tutorial], we saw Jim set up such a server for his work +In the [Tutorial](http://venge.net/monotone/docs/Tutorial.html), we saw Jim set up such a server for his work with Abe and Beth, but this is primarily a convenience. Each person's replica of the repository is as good as any other's, so long as they contain the same information. -== Why do you think you need one? == +## Why do you think you need one? Some people new to monotone have difficulty with this, and see this as a problem. To decide whether it is a problem, the question of why you think you want a master copy is @@ -29,13 +32,13 @@ copy to achieve, perhaps based on your e There are several things you might think you need a master copy to achieve, perhaps based on your established habits or expectations from other systems. -For at least ''some'' of these things, you actually +For at least *some* of these things, you actually don't -- monotone deals with the requirement differently. In other cases, maybe you really do need a centralised rather than a distributed VCS after all. -In the following discussion, remember that there's no reason some repository instances can't be special if you want them to be, it's just that none of them really ''needs'' to be. +In the following discussion, remember that there's no reason some repository instances can't be special if you want them to be, it's just that none of them really *needs* to be. -=== for backups? === +### for backups? You might want a place to ensure you have a safe backup. @@ -52,7 +55,7 @@ revisions that were first put there by s us by someone other than the original author (note that this is the normal case when getting revisions from such a server, because it only contains revisions that were first put there by someone else). -See the TrustFoundations page for more details on cert-based trusts. +See the [[TrustFoundations]] page for more details on cert-based trusts. Restoring the server is simply a matter of putting up an empty server and having people feed it back from their own replicas @@ -66,7 +69,7 @@ any of these databases pretty much inter in dark places -- it just means that you can generally back up any of these databases pretty much interchangably for the same effect. -=== for authoritative reference? === +### for authoritative reference? You might want a place that is considered an authoritative reference about content or history. @@ -81,15 +84,15 @@ different in a distributed system. Mono There might be other kinds of authoritative reference that could be important. Time is a good example of one of those things that are just necessarily different in a distributed system. Monotone stores revision timestamps in certs. It's possible to create a date -cert with an arbitrary value (and, for example, cvs_import will do so, +cert with an arbitrary value (and, for example, cvs\_import will do so, generating certs with cvs's times). Or people's clocks can always just be wrong. So you need to decide what trust to place in them. If 'authoritative' dates are important to you for some reason, you need to establish the authority: have a trusted server add its own date certs when it receives new -revisions over netsync, signed with a purpose-specific key. This server is a timestamping authority, but need not be special in any other way (and other people can choose to trust a different timestamping authority, if they really feel the need). See the TrustFoundations and UsingCerts pages for more information. +revisions over netsync, signed with a purpose-specific key. This server is a timestamping authority, but need not be special in any other way (and other people can choose to trust a different timestamping authority, if they really feel the need). See the [[TrustFoundations]] and [[UsingCerts]] pages for more information. -=== for centralised controls? === +### for centralised controls? You might want a place to enforce centralised controls of various kinds. @@ -106,7 +109,7 @@ and all follow the same set of rules. T Although very powerful, sometimes this is cumbersome to manage, and in a project with a common cause, people just want to agree and all follow the same set of rules. The next major emphasis of -monotone feature development is centered around this TrustDiscussion, +monotone feature development is centered around this [[TrustDiscussion]], to allow users to delegate the specification of project policy to trusted authorities. Note that this will allow centralised publication of those rules, for distributed enforcement. @@ -124,6 +127,6 @@ need to look at a centralised VCS after distributed system and your project is better without them, or you may need to look at a centralised VCS after all. -=== for something else? === +### for something else? You might want it for some other reason; if so, please add it to this page! ============================================================ --- wiki/NeedReview.moin 158c8002ac2ca6897137322bc1bb398d56bab980 +++ wiki/NeedReview.mdwn f1136ce9621aba7094312d6c299fb180929685c8 @@ -1,12 +1,15 @@ +[[tag migration-auto]] + + Branches needing review: * `net.venge.monotone.ssh-agent`: uses the ssh-agent to sign data * no tests yet * no user docs yet - * `mtn ssh_agent_export > id_monotone` - * `chmod 600 id_monotone` + * `mtn ssh\_agent\_export > id\_monotone` + * `chmod 600 id\_monotone` * `ssh-agent /bin/bash` - * `ssh-add id_monotone` + * `ssh-add id\_monotone` * `mtn ci/pull/push/etc` +NB: See [[AutomateMagic]] for a hint on how to generate diffs between the base of a branch and the branch's head. You can also use monotone-viz's `diff with selected node` as an easy way to determine the corresponding nodes and diff the branches. -NB: See AutomateMagic for a hint on how to generate diffs between the base of a branch and the branch's head. You can also use monotone-viz's `diff with selected node` as an easy way to determine the corresponding nodes and diff the branches. ============================================================ --- wiki/NetsyncTodo.moin 61b2da91a2cce50a6c334eb2c5563b5e28d95570 +++ wiki/NetsyncTodo.mdwn 2aa155e140843c5e6682ace11ec6a55063bf0c22 @@ -1,18 +1,24 @@ +[[tag migration-auto]] + + Netsync has served well (no pun intended), but it's become clear over time that we need to rev it. Let's use this page as scratch paper to figure out what the next version should look like. Some things that a new netsync should do: + * leave initiation of merkle refinement up to client (currently it has to be started, and connection finishes when merkle refinement finishes). This allows us to provide other services, things like branch listing or individual key upload, etc., that are hard to fit into the merkle refinement framework. - * PartialPull ? - * something that goes with PartialPull: transparent remote fallback. Several people have suggested that it would be nice to fall back on cvs/svn-style behavior when one's local repository is inadequate -- just dial up the remote server and fetch needed objects on the fly. This avoids a number of sticky issues about what exactly you _do_ do when you need some old stuff temporarily. (Though maybe the only times you need old stuff and don't want to fetch it all properly are for old version browsing that you can just use the web interface for anyway, or something.) - * DagBasedRefinement ? This removes an annoying corner case, and is probably easier than merkle refinement to adapt to working with PartialPull . + * [[PartialPull]] ? + * something that goes with [[PartialPull]]: transparent remote fallback. Several people have suggested that it would be nice to fall back on cvs/svn-style behavior when one's local repository is inadequate -- just dial up the remote server and fetch needed objects on the fly. This avoids a number of sticky issues about what exactly you _do_ do when you need some old stuff temporarily. (Though maybe the only times you need old stuff and don't want to fetch it all properly are for old version browsing that you can just use the web interface for anyway, or something.) + * [[DagBasedRefinement]] ? This removes an annoying corner case, and is probably easier than merkle refinement to adapt to working with [[PartialPull]] . * more coherent story on cross-version compatibility and upgrading * Pull buffering: during a large pull, the client stalls TCP over and over again because revision reconstruction takes lots of CPU so we only read from the network in bursts. Ideally we would be so CPU-efficient that this wouldn't matter, but a cheap and easy hack would be to interpose a process that does nothing but grab data from the network socket as fast as possible and buffer it in memory until the real reader can absorb it. This might also be a win on the server side but I suspect that large pushes are much less frequent so it may not be worth bothering. User requests: + * encryption * finer grained write control Here are things pulled out of comments in netsync.cc, some are out of date: + * need some way to upgrade anonymous to keyed pull, without user having to explicitly specify which they wantjust having a way to respond "access denied, try again" might work but perhaps better to have the anonymous command include a note "I _could_ use key <...> if you prefer", and if that would lead to more access, could reply "I do prefer". (Does this lead to too much information exposure? Allows anonymous people to probe what branches a key has access to.) * How about the client sending a "I could try some keys, too" flags, to which the server responds "access denied, try again" - with the client sending a full authentication instead of just the key-id (where this can be the old key, with wrong password, or a new key) * "warning" packet type? @@ -20,7 +26,8 @@ Things which have been fixed: * add some sort of vhost field to the client's first packet, saying who they expect to talk to Things which have been fixed: - * redone merkle phases, to avoid the complex delayed_writer stuff. Fetch stuff in an order so that you can write it right away; like, use merkle refinement to calculate the list of needed revisions, and then have the source side toposort them and do a single pass through them all, dumping both revision and forward deltas for all files in it. (Alternatively, do a pass through each file history first, to cut down on reconstruction costs on the receiver by not clobbering the reconstruction cache, and then send the revisions proper?) And then figure out certs. Let's give this its own page: NetsyncTodo/MerklePhases + + * redone merkle phases, to avoid the complex delayed\_writer stuff. Fetch stuff in an order so that you can write it right away; like, use merkle refinement to calculate the list of needed revisions, and then have the source side toposort them and do a single pass through them all, dumping both revision and forward deltas for all files in it. (Alternatively, do a pass through each file history first, to cut down on reconstruction costs on the receiver by not clobbering the reconstruction cache, and then send the revisions proper?) And then figure out certs. Let's give this its own page: [[NetsyncTodo]]/MerklePhases * connection teardown is flawed: * simple bug: often connections "fail" even though they succeeded. should figure out why. (Possibly one side doesn't wait for their goodbye packet to drain before closing the socket?) * subtle misdesign: "goodbye" packets indicate completion of data transfer. they do not indicate that data has been written to disk. there should be some way to indicate that data has been successfully written to disk. See message (and thread) on monotone-devel. ============================================================ --- wiki/PathUI.moin e31e427d80b61c6146fd797f0961ee646d1806d3 +++ wiki/PathUI.mdwn 3c85c7d1ed5c07e07294ea68722df2fbe81a3adf @@ -1,63 +1,60 @@ +[[tag migration-auto]] + + Presentation of paths and path handling in general present some interesting UI issues. -= Root Directory Naming = +# Root Directory Naming * the root directory is called "" internally - * sometimes we use this name for the root directory '''externally''' and this is somewhat bad + * sometimes we use this name for the root directory **externally** and this is somewhat bad * other times we simply don't list the root directory because it doesn't have a sensible name For example: -{{{ -$ mtn st -Current branch: foobar -Changes against parent - added - added foobar + $ mtn st + Current branch: foobar + Changes against parent + added + added foobar + + $ mtn ls known + foobar -$ mtn ls known -foobar -}}} +# Relative Names -= Relative Names = - * current situation - * paths are always '''displayed''' relative to the workspace root - * paths are '''interpreted''' relative to the current directory + * paths are always **displayed** relative to the workspace root + * paths are **interpreted** relative to the current directory * problem * output from ls unknown/ignonred/missing/changed is used as input for other scripts/commands by some people. this does not work properly if these commands are run from within a subdirectory of the workspace because the paths are displayed relative to the workspace root rather than the current directory * solution - * '''display''' paths relative to the current working directory + * **display** paths relative to the current working directory * downsides of that solution * if cwd is a subdirectory of the workspace, and the user doesn't restrict to the current working directory, the ls commands are likely to output a lot of paths that are pointing to paths outside of that directory and thus would be displayed as "../foo/bar". on the ml it has been pointed out that paths containing '..' can be ambigous when symlinks are present. * consistency: output of other commands (status, diff) is not likely to be changed, so we would loose conistency there -= Peg Revision Syntax = +# Peg Revision Syntax * we need some way of naming paths with respect to a specific revision * consider restriction of renames whic will match on either the old or the new path * ideally we should be able to say "path in revision " For example consider the following: -{{{ -$ mtn rename foo bar -$ mtn add foo -$ mtn revert foo -}}} + $ mtn rename foo bar + $ mtn add foo + $ mtn revert foo -The "foo" given to mtn revert will match '''both''' the file that was renamed to bar and the new file that was added. If one wanted to only revert the addition they should be able to say something like: -{{{ -$ mtn revert address@hidden -}}} +The "foo" given to mtn revert will match **both** the file that was renamed to bar and the new file that was added. If one wanted to only revert the addition they should be able to say something like: + $ mtn revert address@hidden -See also ["RevertUI"]. +See also ["[[RevertUI]]"]. -We do currently have a way of doing ''almost'' this: {{{automate get_corresponding_path REV1 FILE REV2}}} will allow you to translate the name as it existed in one rev to the name of the corresponding nid in REV2. If you're working in the context of REV2, you can now use this translated path instead of the other name... provided the nid still exists to have a path in REV2. +We do currently have a way of doing *almost* this: `automate get\_corresponding\_path REV1 FILE REV2` will allow you to translate the name as it existed in one rev to the name of the corresponding nid in REV2. If you're working in the context of REV2, you can now use this translated path instead of the other name... provided the nid still exists to have a path in REV2. -Conceptually, paths only exist in the context of some revision so while the '''address@hidden''' syntax is somewhat common it seems somewhat inverted. Perhaps something that represents this hierarchy (i.e. puts the '''REV''' before the '''path''') would be better. +Conceptually, paths only exist in the context of some revision so while the address@hidden syntax is somewhat common it seems somewhat inverted. Perhaps something that represents this hierarchy (i.e. puts the **REV** before the **path**) would be better. -The idea of '''//REV/path''' doesn't work so well since REV is really a selector and selectors already use the "/" character. +The idea of **//REV/path** doesn't work so well since REV is really a selector and selectors already use the "/" character. -= Depth Syntax = +# Depth Syntax The current --depth option applies to all paths named in a restriction. However these paths may represent directories at different levels in the hierarchy and a single --depth option may not make the most sense. Ideally, each directory named in a restriction could allow a specific depth value. ============================================================ --- wiki/ReferenceCard.moin 27c20f68f0afe149e820051d4e245c50740fa7b2 +++ wiki/ReferenceCard.mdwn 8eabb57e91e3aa5a738b991ee04264f6e0eb903b @@ -1,35 +1,38 @@ -Monotone should have a refcard like [http://www.cs.put.poznan.pl/csobaniec/edu/svn-refcard.pdf this]. +[[tag migration-auto]] -Also, the work started on an SVG-based cheat-sheet in the contrib/ directory named [http://mtn-host.prjek.net/viewmtn/monotone/revision/downloadfile/e45bd38d526fa88be934e052943541f7cffa2167/contrib/mtn_cheat_sheet.svg mtn_cheat_sheet.svg]. -= Quick Start = -|| {{{mtn db init --db=~/DbName.mtn}}} || initialize database ''Db''''''Name.mtn'' || -|| {{{mtn genkey address@hidden || generate key for user ''yourname''''''@somplace.com''|| -|| {{{mtn --db=DbName.mtn --branch=com.someplace.myproject setup myproject}}} || start project ''myproject'' || -|| {{{mtn add SomeFile.c SomeDir/ }}} || start version control for {{{SomeFile.c}}} and all contents of {{{SomeDir/}}} || -|| {{{mtn status}}} || show rough changes since last commit || -|| {{{mtn diff}}} || show detailed changes since last commit || -|| {{{mtn revert}}} ''filename'' || revert changes made to working copy of ''filename'' || -|| {{{mtn drop}}} ''filename'' || stop keeping track of ''filename'' || -|| {{{mtn commit}}} || commit changes || -|| {{{mtn --db ~/DbName.mtn --branch=com.someplace.myproject checkout}}} || checkout com.someplace.myproject || +Monotone should have a refcard like [this](http://www.cs.put.poznan.pl/csobaniec/edu/svn-refcard.pdf). -= Subcommands = +Also, the work started on an SVG-based cheat-sheet in the contrib/ directory named [mtn\_cheat\_sheet.svg](http://mtn-host.prjek.net/viewmtn/monotone/revision/downloadfile/e45bd38d526fa88be934e052943541f7cffa2167/contrib/mtn\_cheat\_sheet.svg). + +# Quick Start +|| `mtn db init --db=~/DbName.mtn` || initialize database *Db*''*Name.mtn* || +|| `mtn genkey address@hidden || generate key for user *yourname*''address@hidden|| +|| `mtn --db=[[DbName]].mtn --branch=com.someplace.myproject setup myproject` || start project *myproject* || +|| `mtn add [[SomeFile]].c [[SomeDir]]/ ` || start version control for `[[SomeFile]].c` and all contents of `[[SomeDir]]/` || +|| `mtn status` || show rough changes since last commit || +|| `mtn diff` || show detailed changes since last commit || +|| `mtn revert` *filename* || revert changes made to working copy of *filename* || +|| `mtn drop` *filename* || stop keeping track of *filename* || +|| `mtn commit` || commit changes || +|| `mtn --db ~/DbName.mtn --branch=com.someplace.myproject checkout` || checkout com.someplace.myproject || + +# Subcommands || list / ls || list contents of database || || serve || serve database to network || -= Share = +# Share (Note, this requires the same version of monotone on both hosts.) -|| {{{mtn sync ssh://address@hidden/absolute/path/to/database/DbName.mtn "my.branch"}}} || sync repository using ssh|| -|| {{{mtn --db ~/DbName.mtn sync ssh://address@hidden/~/OtherDb.mtn "my.branch*"}}} || relative paths also work in a URI || +|| `mtn sync ssh://address@hidden/absolute/path/to/database/DbName.mtn "my.branch"` || sync repository using ssh|| +|| `mtn --db ~/DbName.mtn sync ssh://address@hidden/~/OtherDb.mtn "my.branch*"` || relative paths also work in a URI || -= Common Options = -|| {{{--db}}} || local database to use || +# Common Options +|| `--db` || local database to use || -= Naming Conventions = +# Naming Conventions Derive public visible names from domain-names you control. Project names are usually in reverse order. -= Files = +# Files || _MTN/ || monotone control directory within project|| ============================================================ --- wiki/RoadMap.moin 3447ec0bac245b5bf02e091431261fb57a564480 +++ wiki/RoadMap.mdwn 4c332cd19ef0c4ce2a6005ee54f515539b0cde98 @@ -1,83 +1,86 @@ +[[tag migration-auto]] + + This page summarizes what is left to do and who is in charge for what tasks which should be done before monotone 1.0 hits the world. If there is no contact person for a certain work piece yet and you feel responsible for it, put in your name and IRC nick. -There is also an unsorted list of QuickieTasks which should help you get in contact with monotone if you like to start on it. +There is also an unsorted list of [[QuickieTasks]] which should help you get in contact with monotone if you like to start on it. -== Policy Branches == +## Policy Branches Contact person(s): Nathaniel Smith (njs), Paul Crowley (ciphergoth) Branch(es): net.venge.monotone.experimental.policy-branches* -Entry page(s): VersionedPolicy +Entry page(s): [[VersionedPolicy]] State: ?% (awaiting feedback on proposals since 2007-02-07) -== Command naming and UI cleanups == +## Command naming and UI cleanups Contact person(s): Thomas Keller (tommyd) -Branch(es): net.venge.monotone.commit_without_-b +Branch(es): net.venge.monotone.commit\_without_-b Entry page(s): ? State: ?% (waiting for feedback how to continue with the current implementation of mtn branch) -== Selector overhaul == +## Selector overhaul Contact person(s): ? Branch(es): ? -Entry page(s): MagicSelectors +Entry page(s): [[MagicSelectors]] State: ?% -== CVS import with branch reconstruction == +## CVS import with branch reconstruction Contact person(s): Markus Schiltknecht Branch(es): net.venge.monotone.cvsimport-branch-reconstruction -Entry page(s): CvsImport +Entry page(s): [[CvsImport]] State: ?% -== CVS <=> monotone synchronization == +## CVS <=> monotone synchronization Contact person(s): Christof Petig (christof), William Uther (willu) Branch(es): net.venge.monotone.cvssync* -Entry page(s): CvsSync3 +Entry page(s): [[CvsSync3]] State: ?% -== Workspace merge: conflict handling == +## Workspace merge: conflict handling Contact person(s): Timothy Brownawell (tbrownaw) Branch(es): net.venge.monotone.workspace-merge* -Entry page(s): MergeViaWorkingDir +Entry page(s): [[MergeViaWorkingDir]] State: ?% -== Automation expansions == +## Automation expansions Contact person(s): Derek Scherger (dscherger), Thomas Moschny (thm), Thomas Keller (tommyd) -Branch(es): net.venge.monotone.basic_io.inventory (''DONE'', merged to mainline at 07ae9cb), net.venge.monotone.revision_diff, net.venge.monotone.automate_current_revision +Branch(es): net.venge.monotone.basic\_io.inventory (*DONE*, merged to mainline at 07ae9cb), net.venge.monotone.revision\_diff, net.venge.monotone.automate\_current\_revision -Entry page(s): AutomateWishlist +Entry page(s): [[AutomateWishlist]] State: 33% -= Template = +# Template -== Project name == +## Project name Contact person(s): Firstname Lastname (irc nick), ... ============================================================ --- wiki/RootDirRenaming.moin 552c48fffb292782ac0c6c349fe2de73c1df7af7 +++ wiki/RootDirRenaming.mdwn 4a65605d808d4707174b50609c35fb31df0b6fb8 @@ -1,17 +1,22 @@ +[[tag migration-auto]] + + The ability to change root dirs is needed for 0.26, so people with existing root dir sutures can migrate. There is a branch for this: `net.venge.monotone.root-dir-rename` The branch has: + * rosters have the ability to change roots - * roster_merge handles the new conflict cases this allows + * roster\_merge handles the new conflict cases this allows The branch needs: - * an implementation of pivot_root - * NB: make sure to refuse to pivot_root if the proposed new root has a subdir named "MT" + + * an implementation of pivot\_root + * NB: make sure to refuse to pivot\_root if the proposed new root has a subdir named "MT" * lots of tests * make the roster.cc test automaton generate root dir stuff - * roster_merge stuff - * pivot_root stuff + * roster\_merge stuff + * pivot\_root stuff * rosterify on db with root sutures * ? ============================================================ --- wiki/SpeedySpeedySHA1.moin 74a27e7945604bed19c1903c5d1d15be501552cc +++ wiki/SpeedySpeedySHA1.mdwn 5cd0afa39d5049c12ce9c5255d35f3cfebdfda20 @@ -1,82 +1,85 @@ -There are a number of performance issues and possible bottlenecks in monotone. Some of these represent work we do unnecessarily, where algorithms or implementations have been developed for correctness first, and now are being optimised for performance. There is room for ''significant'' improvement of this kind in a number of areas, and we're attacking several of these bottlenecks as we find them. +[[tag migration-auto]] + +There are a number of performance issues and possible bottlenecks in monotone. Some of these represent work we do unnecessarily, where algorithms or implementations have been developed for correctness first, and now are being optimised for performance. There is room for *significant* improvement of this kind in a number of areas, and we're attacking several of these bottlenecks as we find them. + One thing is going to remain: monotone will always do a lot of SHA1 operations, and this work is fundamental and unavoidable. As other bottlenecks are removed and improvements are made, proportionally more and more of the remaining time monotone spends, will be spent doing SHA1. So it'd be nice to have a really fast SHA1 in botan for us. "Really fast", these days, means hand-tuned asm; such cores can (in extreme cases) be as much as 4x faster than optimized C. -= Sources = +# Sources -== ARM == +## ARM - * Git has GPLed arm-optimized SHA1: see directory [http://www.kernel.org/git/?p=git/git.git;a=tree;f=arm arm] in the source tree. This is just a few self-contained files (.c and .S) exporting a simple interface. + * Git has GPLed arm-optimized SHA1: see directory [arm](http://www.kernel.org/git/?p=git/git.git;a=tree;f=arm) in the source tree. This is just a few self-contained files (.c and .S) exporting a simple interface. -== PPC == +## PPC - * Git has GPLed ppc-optimized SHA1: see directory [http://www.kernel.org/git/?p=git/git.git;a=tree;f=ppc ppc] in the source tree. This is just a few self-contained files (.c and .S) exporting a simple interface. + * Git has GPLed ppc-optimized SHA1: see directory [ppc](http://www.kernel.org/git/?p=git/git.git;a=tree;f=ppc) in the source tree. This is just a few self-contained files (.c and .S) exporting a simple interface. - * OpenSSL has BSD+advertising licensed ppc-optimized SHA1: see directory [http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm crypto/sha/asm] in the source distribution; the ppc code also depends on [http://cvs.openssl.org/rlog?f=openssl/crypto/perlasm/ppc-xlate.pl crypto/perlasm/ppc-xlate.pl] to post-process the output for portability. Both of these files are copyright Andy Polyakov, who is willing to relicense them (see below). + * [[OpenSSL]] has BSD+advertising licensed ppc-optimized SHA1: see directory [crypto/sha/asm](http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm) in the source distribution; the ppc code also depends on [crypto/perlasm/ppc-xlate.pl](http://cvs.openssl.org/rlog?f=openssl/crypto/perlasm/ppc-xlate.pl) to post-process the output for portability. Both of these files are copyright Andy Polyakov, who is willing to relicense them (see below). -== IA64 == +## IA64 - * OpenSSL has BSD+advertising licensed ia64-optimized SHA1: see directory [http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm crypto/sha/asm] in the source distribution. This file is copyright Andy Polyakov, who is willing to relicense it (see below). + * [[OpenSSL]] has BSD+advertising licensed ia64-optimized SHA1: see directory [crypto/sha/asm](http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm) in the source distribution. This file is copyright Andy Polyakov, who is willing to relicense it (see below). -== x86-64 == +## x86-64 - * OpenSSL has BSD+advertising licensed x86-64-optimized SHA1: see directory [http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm crypto/sha/asm] in the source distribution; the x86-64 code also depends on [http://cvs.openssl.org/rlog?f=openssl/crypto/perlasm/x86_64-xlate.pl crypto/perlasm/x86_64-xlate.pl] to post-process the output for portability. Both of these files are copyright Andy Polyakov, who is willing to relicense them (see below). + * [[OpenSSL]] has BSD+advertising licensed x86-64-optimized SHA1: see directory [crypto/sha/asm](http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm) in the source distribution; the x86-64 code also depends on [crypto/perlasm/x86_64-xlate.pl](http://cvs.openssl.org/rlog?f=openssl/crypto/perlasm/x86_64-xlate.pl) to post-process the output for portability. Both of these files are copyright Andy Polyakov, who is willing to relicense them (see below). -== x86 == +## x86 - * OpenSSL has BSD+advertising licensed x86-optimized SHA1: see directory [http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm crypto/sha/asm] in the source distribution. ''However'', this code cannot be relicensed. ''However however'', Andy Polyakov may rewrite it when he gets back from vacation (see below). + * [[OpenSSL]] has BSD+advertising licensed x86-optimized SHA1: see directory [crypto/sha/asm](http://cvs.openssl.org/dir?d=openssl/crypto/sha/asm) in the source distribution. *However*, this code cannot be relicensed. *However however*, Andy Polyakov may rewrite it when he gets back from vacation (see below). - * [http://sourceforge.net/projects/beecrypt/ beecrypt] has LGPLed x86-optimized SHA1; however, it is not very fast, at least on P4. See http://article.gmane.org/gmane.comp.version-control.monotone.devel/7773. + * [beecrypt](http://sourceforge.net/projects/beecrypt/) has LGPLed x86-optimized SHA1; however, it is not very fast, at least on P4. See http://article.gmane.org/gmane.comp.version-control.monotone.devel/7773. - * [http://www.lysator.liu.se/~nisse/nettle/ nettle] (site may be down, but debian for instance has the source) has GPLed x86-optimized SHA1; it is pretty fast, but (at least on P4) not nearly as fast as openssl. See http://article.gmane.org/gmane.comp.version-control.monotone.devel/7773. + * [nettle](http://www.lysator.liu.se/~nisse/nettle/) (site may be down, but debian for instance has the source) has GPLed x86-optimized SHA1; it is pretty fast, but (at least on P4) not nearly as fast as openssl. See http://article.gmane.org/gmane.comp.version-control.monotone.devel/7773. -= TODO = +# TODO -== General == +## General - * Write the basic framework to plug in replacement SHA1 "engines" to botan -- the basic configury, plus somewhere where we call add_engine() when we have one compiled in, etc. + * Write the basic framework to plug in replacement SHA1 "engines" to botan -- the basic configury, plus somewhere where we call add\_engine() when we have one compiled in, etc. * This is very straightforward, and explained at http://article.gmane.org/gmane.comp.version-control.monotone.devel/7674 - * JackLloyd also says: ''It's reasonably simple, on the order of 100 LOC. Take a look at modules/eng_ossl/ossl_md.cpp for an example. The documentation is pretty lacking in this area, but I (JackLloyd) would be happy to walk someone through it.'' + * [[JackLloyd]] also says: ''It's reasonably simple, on the order of 100 LOC. Take a look at modules/eng\_ossl/ossl\_md.cpp for an example. The documentation is pretty lacking in this area, but I (JackLloyd) would be happy to walk someone through it.'' - * Add a small sha1 benchmark to monotone -- 'mtn benchmark_sha1' or something, as a hidden command -- that runs sha1 over some number of bytes and times the result, using botan's portable SHA1, then whatever optimized version(s) we may have available. It may be useful to compile in multiple cores for the same architecture, at least at first, so that we can ask users to run this command and send us the results, to determine which cores are best on different cpus. + * Add a small sha1 benchmark to monotone -- 'mtn benchmark\_sha1' or something, as a hidden command -- that runs sha1 over some number of bytes and times the result, using botan's portable SHA1, then whatever optimized version(s) we may have available. It may be useful to compile in multiple cores for the same architecture, at least at first, so that we can ask users to run this command and send us the results, to determine which cores are best on different cpus. -== Git-derived cores == +## Git-derived cores * Just drop in the arm/ and ppc/ directories to monotone, and write a trivial engine that just calls into the C source. Open questions: + * Will these build and work on windows with mingw? -== OpenSSL-derived cores == +## [[OpenSSL]]-derived cores * Andy Polyakov has agreed to re-license, but on August 10 he said he is leaving for a couple weeks vacation, and so will be offline until late August. * He will likely re-write the 32-bit x86 code to remove the license encumberance when he gets back. * We owe him a postcard :-). I (NathanielSmith) will send him one, but if anyone else wants to too: -{{{ -Andy Polyakov -Sven Hultinsgata 12a -Chalmers University of Technology -Gothenburg -SE-412 96 SWEDEN -}}} + Andy Polyakov + Sven Hultinsgata 12a + Chalmers University of Technology + Gothenburg + SE-412 96 SWEDEN Once licensing is settled: * Figure out what to do with the perlyness of the code (both because it might let us simplify things a bit, and also because the x86 perlasm portability code is license-encumbered): * On a very casual skim through these files, I believe that they can easily be de-perl-ified -- the point of the perl is to use the same source for several different assemblers / object file formats, and I think they're working much harder than they need to on that score. For our purposes, it would be okay to have two copies, one that was correct for ELF/Unix and one that was correct for PE/Windows, and we could be pretty picky about which assemblers we supported; thus for instance we could use GAS's built-in macro facility, or GCC's ability to run assembly through the C preprocessor. -- Zack - * But Andy says: ''No, not only that. Perl is also used to generate unrolled loops and assign more comprehensible names to registers. In other words perl makes it manageable.'' + * But Andy says: *No, not only that. Perl is also used to generate unrolled loops and assign more comprehensible names to registers. In other words perl makes it manageable.* * I also wonder about whether it is difficult, or we care, to support non-GNU toolchains at all. I believe that on Solaris we might build with the native toolchain, for instance? * Integrate into the build system/configury - * Drop in the Botan engine that calls into the asm (NB, we can't use anything _but_ the asm cores; the stuff in OpenSSL that does buffering and what-have-you is also license-encumbered). JackLloyd already wrote the relevant code: http://article.gmane.org/gmane.comp.version-control.monotone.devel/7681 + * Drop in the Botan engine that calls into the asm (NB, we can't use anything _but_ the asm cores; the stuff in [[OpenSSL]] that does buffering and what-have-you is also license-encumbered). [[JackLloyd]] already wrote the relevant code: http://article.gmane.org/gmane.comp.version-control.monotone.devel/7681 Open questions: - * does the OpenSSL x86 core (labeled "i586") work on i486? (g++ already doesn't support i386, so not much point in worrying about that...) + + * does the [[OpenSSL]] x86 core (labeled "i586") work on i486? (g++ already doesn't support i386, so not much point in worrying about that...) * will the x86 and x86-64 cores build and work on windows with mingw? -== Nettle == +## Nettle * Just pull out the relevant pieces (or optionally link to libnettle), and hook them into Botan. ============================================================ --- wiki/TestHarnessUseCases.moin 2ab96b3a8d76346d2dd452319fce4e14455bb690 +++ wiki/TestHarnessUseCases.mdwn 0742f9b49266074e3fb2e1f7ad5d40393181df16 @@ -1 +1,4 @@ -#redirect TestHarnessIssues +[[tag migration-auto]] + + +#redirect [[TestHarnessIssues]] ============================================================ --- wiki/ThingsStatusShouldShow.moin e41153911464e829bf824d87f4386d3fe6d4cbc4 +++ wiki/ThingsStatusShouldShow.mdwn d00fc6eec6935d8b05030ca469b483b7bfc7df50 @@ -1,15 +1,19 @@ +[[tag migration-auto]] + + Seriously, `mtn status` doesn't really have the friendliest UI. Things it should tell: + * what's changed in the current working copy (in concise, human-friendly, i18nized form) - * when we have MergeViaWorkingDir: versus both parents + * when we have [[MergeViaWorkingDir]]: versus both parents * what branch we're on * what the base revision is (?) * unknown files (listing them if just a few, suppressing the list to say " unknown files" if there are lots) * missing files (currently status will fail if there are missing files) * if there are other heads (maybe only if we're at the head? i.e., hint about running `merge`) * if update would do anything (maybe details on what it would do, if they're short? i.e., listing files that would be affected if you hit `update` now?) - * when we have MergeViaWorkingDir: unresolved conflicts + * when we have [[MergeViaWorkingDir]]: unresolved conflicts Other cool status things ============================================================ --- wiki/TipsTricksScripts.moin f00b50558d9c0e8440a20af52615c34edb93452e +++ wiki/TipsTricksScripts.mdwn 70eda9f9121aa26cc4d2a47d15711af9c2934872 @@ -1,9 +1,12 @@ -= Tips, Tricks and Scripts = +[[tag migration-auto]] + +# Tips, Tricks and Scripts + Clever ways to get more out of Monotone. + * [[DaggyFixes]] + * [[BranchRenaming]] + * [[RosterifyingPrivateBranches]] + * [[RelativePathnames]] + * [[UnixAttribsAndSymlinks]] - * DaggyFixes - * BranchRenaming - * RosterifyingPrivateBranches - * RelativePathnames - * UnixAttribsAndSymlinks ============================================================ --- wiki/WishList.moin 16675af8512ab789c5aae0990a95cde540dab065 +++ wiki/WishList.mdwn a30d547ba5925639d727c23d4004c45c546edd29 @@ -1,16 +1,19 @@ -== What features are missing from Monotone? == +[[tag migration-auto]] -''and what is being done to fix them...'' -Other pages that are relevant include the QuickieTasks, [wiki:Self:InterfacesFrontendsAndTools#wishes InterfacesFrontendsAndTools], AutomateWishlist, [wiki:Self:LogUI LogUI], NetsyncTodo, DocTodo, MergeViaWorkingDir and MtnSummitWishes pages. +## What features are missing from Monotone? -=== UI improvements === +*and what is being done to fix them...* -If you look at the [http://monotone.ca/docs/CVS-Phrasebook.html CVS Phrasebook] in the monotone manual you'll see a bunch of places where a single CVS command corresponds to multiple mtn commands. Convenience commands could help here: +Other pages that are relevant include the [[QuickieTasks]], [wiki:Self:[[InterfacesFrontendsAndTools]]#wishes [[InterfacesFrontendsAndTools]]], [[AutomateWishlist]], [wiki:Self:[[LogUI]] [[LogUI]]], [[NetsyncTodo]], [[DocTodo]], [[MergeViaWorkingDir]] and [[MtnSummitWishes]] pages. - * mtn remote-commit or rcommit or rci == mtn commit && mtn pull ''branch'' && mtn merge && mtn push ''branch'' - * mtn remote-update or rupdate or rup == mtn pull ''branch'' && mtn merge && mtn update +### UI improvements +If you look at the [CVS Phrasebook](http://monotone.ca/docs/CVS-Phrasebook.html) in the monotone manual you'll see a bunch of places where a single CVS command corresponds to multiple mtn commands. Convenience commands could help here: + + * mtn remote-commit or rcommit or rci == mtn commit && mtn pull *branch* && mtn merge && mtn push *branch* + * mtn remote-update or rupdate or rup == mtn pull *branch* && mtn merge && mtn update + And/Or * Add a --merge and --update options to pull and sync @@ -20,50 +23,51 @@ The net.venge.monotone.lua-cmds branch ( ==== Other UI stuff ==== -mtn status should include mtn ls unknown. See [http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00336.html this email] for a description of what is planned. +mtn status should include mtn ls unknown. See [this email](http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00336.html) for a description of what is planned. -Why isn't a -b argument to mtn log a synonym for -r h:? See [wiki:Self:LogUI LogUI]. +Why isn't a -b argument to mtn log a synonym for -r h:? See [wiki:Self:[[LogUI]] [[LogUI]]]. Why does mtn pull allow anonymous pull, but mtn sync doesn't fall back to the anonymous case? -There should be an option for pull and sync to print out the log entries of revisions received. This can be achived with the {{{note_netsync_revision_received}}} hook. +There should be an option for pull and sync to print out the log entries of revisions received. This can be achived with the `note\_netsync\_revision\_received` hook. Monotone could use a subcommand such as "newbranch", with the only purpose to change _MTN/options with the name of the new branch. -The ability to mark branches as "unused". i.e. abandonded or merged. If you go to the main monotone [http://viewmtn.angrygoats.net/ viewmtn] web page you see 165 branches with 'monotone' in the name. I suspect that a number of those have been merged and/or abandoned. It would be nice to know which. +The ability to mark branches as "unused". i.e. abandonded or merged. If you go to the main monotone [viewmtn](http://viewmtn.angrygoats.net/) web page you see 165 branches with 'monotone' in the name. I suspect that a number of those have been merged and/or abandoned. It would be nice to know which. It would be good if there were a convention that branches of the monotone repository had a readme.branchname file describing the branch. -Transformations on source. This includes EOLN conversion, Keyword expansion (e.g. $Id$), archive explosion (so that files in the archive get versioned separately) and decompression (you should always diff decompressed versions of files). Some comments on this are [http://lists.gnu.org/archive/html/monotone-devel/2006-12/msg00079.html here], [http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00318.html here] and [http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00322.html here]. The comments revolve around whether the transformation should be done in monotone or external to monotone. +Transformations on source. This includes EOLN conversion, Keyword expansion (e.g. $Id$), archive explosion (so that files in the archive get versioned separately) and decompression (you should always diff decompressed versions of files). Some comments on this are [here](http://lists.gnu.org/archive/html/monotone-devel/2006-12/msg00079.html), [here](http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00318.html) and [here](http://lists.gnu.org/archive/html/monotone-devel/2007-02/msg00322.html). The comments revolve around whether the transformation should be done in monotone or external to monotone. Notes: + * Keywords should be stored in a canonical form (e.g. $Rev: $, not $Rev: ab34...$) and re-expanded on checkout * You can't put a file's hash inside the file itself * It stops spurious conflicts on merge * Needs to be efficient. Needs to be consistent across users in a project. Needs to be secure (no plugins read from the workspace). -=== Backing store / database improvements === +### Backing store / database improvements -Anonymous pull over http. The ability to export from a database to a set of files and back again is in the {{{net.venge.monotone.dumb}}} branch. Unfortunately this is a separate python wrapper around the `mtn automate` command. You cannot pull from the filedir/http server using a normal client. It was noted in the discussion about this on the mailing list that there is no obvious C++ http library. libcurl was best and it doesn't support pipelining. Maybe the solution is to not have pipelining to begin with. +Anonymous pull over http. The ability to export from a database to a set of files and back again is in the `net.venge.monotone.dumb` branch. Unfortunately this is a separate python wrapper around the `mtn automate` command. You cannot pull from the filedir/http server using a normal client. It was noted in the discussion about this on the mailing list that there is no obvious C++ http library. libcurl was best and it doesn't support pipelining. Maybe the solution is to not have pipelining to begin with. -Anonymous push over email attachments. Something like {{{mtn push-email repos > attachment}}}. Then you email the attachment. The receiver uses {{{mtn read < attachment}}}. The push-email command needs to be in the standard client. {{{mtn push-email}}} should figure out what to push just like a normal push, but then write the packets to std-out rather than netsync. +Anonymous push over email attachments. Something like `mtn push-email repos > attachment`. Then you email the attachment. The receiver uses `mtn read < attachment`. The push-email command needs to be in the standard client. `mtn push-email` should figure out what to push just like a normal push, but then write the packets to std-out rather than netsync. -Extend db kill_rev_locally so that you can kill anything not in a remote repository. This is related to push, but instead of pushing, it kills the local revisions. Much faster than re-downloading the entire remote db. +Extend db kill\_rev\_locally so that you can kill anything not in a remote repository. This is related to push, but instead of pushing, it kills the local revisions. Much faster than re-downloading the entire remote db. -Moving back and forth to a cvs repository. See the {{{net.venge.monotone.cvssync.refactor}}} branch and CvsSync. +Moving back and forth to a cvs repository. See the `net.venge.monotone.cvssync.refactor` branch and [[CvsSync]]. Moving back and forth to a svn repository. -A ''first class'' ssh:// syncing protocol. At the moment only the netsync server can handle high concurrency, and there is a bug that sometimes causes deadlock piping to sub-processes on windows. See DatabaseLocking. +A *first class* ssh:// syncing protocol. At the moment only the netsync server can handle high concurrency, and there is a bug that sometimes causes deadlock piping to sub-processes on windows. See [[DatabaseLocking]]. -Partial pull. At the moment it takes too long to grab a whole repository for a simple checkout of head. See PartialPull. Partial pull should have an option to seamlessly fall back to a parent repository for missing information. Bonus points for making the parent repository selectable by branch. +Partial pull. At the moment it takes too long to grab a whole repository for a simple checkout of head. See [[PartialPull]]. Partial pull should have an option to seamlessly fall back to a parent repository for missing information. Bonus points for making the parent repository selectable by branch. -Speed improvements. See PerformanceWork. +Speed improvements. See [[PerformanceWork]]. -Stabilize [http://trac.edgewall.org/ Trac] plugin. See [http://tracmtn.1erlei.de/ TracMtn] for the current plugin. +Stabilize [Trac](http://trac.edgewall.org/) plugin. See [TracMtn](http://tracmtn.1erlei.de/) for the current plugin. Pre-sync checks so you could make a netsync server that checked whether after the sync it would have multiple heads on any branch, and reject any such syncs. To use such a server, you'd have to do a pull and a local merge before you push. If someone else commits before you push, you might have to pull and merge again (just like a commit on cvs or svn). Or: a hook script that turns off 'push-only' syncs. If you introduce multiple heads in the remote server, you must end up with them too. Your suggestion or suggestions here... -=== Improve source code build system === +### Improve source code build system Use cross platform build system. Currently VC8 project files are almost always out of date. By switching CMake we'll be able to build on any system from the same source. In addition CMake will eliminate the need for ./configure scripts and automake tools.