Improve it

bugs / todo list
bugs
mailing list
IRC (logs)
wiki
self-hosting info
savannah
self-hosting info
browse source
latest work (RSS)
commit mailing list:
============================================================ --- wiki/AlternativeOverview.mdwn 527af6d692dfc2fc3eb9a05a52c612c52e56eec3 +++ wiki/AlternativeOverview.mdwn c4c211a67e6a21c00468d6783c62ece443eb2112 @@ -1,7 +1,7 @@ [[tag migration-auto]] -*(Though there is a [Monotone manual](http://venge.net/monotone/docs/index.html), this alternative presentation of concepts may be of use. It might be possible to refine this into an article that is the appropriate size, scope, and neutrality to be suited for integration into the [Monotone Wikipedia article](http://en.wikipedia.org/wiki/Monotone_%28software%29).)* +*(Though there is a [Monotone manual](http://monotone.ca/docs/index.html), this alternative presentation of concepts may be of use. It might be possible to refine this into an article that is the appropriate size, scope, and neutrality to be suited for integration into the [Monotone Wikipedia article](http://en.wikipedia.org/wiki/Monotone_%28software%29).)* ## P2P Database Basics @@ -12,13 +12,13 @@ Each archive snapshot is called a *revis Each archive snapshot is called a *revision*. A directory can be added into the *monotone database* using a command called **setup**. When a new *revision* has been *setup* into a *monotone database*, a number known as a *revision ID* is automatically generated to identify it. '''(eds: technically, setup remembers what database you want to associate with, but can't generate a revision id yet. revision id's are only ever generated by a commit)''' -Unlike adding files to a ".zip" or a ".tar", a directory that has been *setup* into a *monotone database* retains a connection to that database and is known as a **workspace**. Hidden files in the *workspace* are used to remember the *revision id* that was generated. Because monotone remembers what files were extracted, you can issue a command called *commit* to generate another *revision* using the same list of files (unless told to do otherwise). +Unlike adding files to a ".zip" or a ".tar", a directory that has been *setup* into a *monotone database* retains a connection to that database and is known as a **workspace**. Hidden files in the *workspace* are used to remember the *revision id* that was generated. Because monotone remembers what files were extracted, you can issue a command called *commit* to generate another *revision* using the same list of files (unless told to do otherwise). ### Extracting Once a *revision ID* is known, you may extract the archive that corresponds to that *revision* into a directory, using a command called **checkout**. If you want to extract an archive into a directory that already exists...use the **update** command. Just as with *setup*, performing a *checkout* or *update* keeps a connection between a *workspace* and a *monotone database*. '''(eds: er, you can update in a workspace that already exists. i don't believe you can run update in any old directory and have it work.)''' - + ### Transferring *Revisions* can be transferred from one *monotone database* into another. The monotone application is able to run as a server and accept requests from another instance of monotone running as a client. These client requests can **push** *revisions* from the client's *monotone database* into one residing on the server. They can also **pull** *revisions* from the server and into a *monotone database* managed by the client. @@ -38,7 +38,7 @@ Security and network authorization in Mo ## Versioning in Monotone -Most of Monotone's interesting features are enabled by tracking a concept of how one *revision* relates to another in conceptual sequence. +Most of Monotone's interesting features are enabled by tracking a concept of how one *revision* relates to another in conceptual sequence. '''(eds: technically the set of revisions forms a directed acyclic graph. don't know if that's appropriate to point out for your target audience or not. the fact that it is *acyclic* does matter though.)''' ### Hierarchy ============================================================ --- wiki/DeltaStorageStrategies.mdwn 9aeef3ce1d8016fba4407bd286f6cc7d6ffb191a +++ wiki/DeltaStorageStrategies.mdwn 8d959a853fd67a77259fda7abfb72c7a0654799d @@ -32,13 +32,13 @@ Netsync also wants to send exactly what ## Forward versus Reverse Linear Chains -The advantage of reverse linear chains seems to be that the most common accesses (check-outs) -are against the end of the chain which in a reverse linear chain means there are no deltas to +The advantage of reverse linear chains seems to be that the most common accesses (check-outs) +are against the end of the chain which in a reverse linear chain means there are no deltas to apply. But a reverse linear chain makes netsync difficult. A forward linear chain would help out netsync, but it has the disadvantage that you have to follow the whole chain of deltas from beginning to end in order to get the latest version. -Perhaps one can meet both needs by keeping a forward linear chain +Perhaps one can meet both needs by keeping a forward linear chain but also keeping a cache of fulltext of the N most recently accessed files. Or perhaps the cache just contains a copy of the end of each chain. In this way, netsync gets the benefit of a forward chain and check-outs can usually be fulfilled from @@ -48,7 +48,7 @@ To counteract increased netsync traffic To counteract increased netsync traffic using against-base deltas, applying zlib to the entire stream (rather than per-packet) seems to make against-base deltas comparable to linear deltas. (I think this requires the assumption that we send related deltas together at netsync time, i.e. sort by file.) -See the au.asn.ucc.matt.monotone.test-deltas branch in the main venge.net repository for a test script and [sample output](http://matt.ucc.asn.au/monotone/delta-screenshot.txt). +See the au.asn.ucc.matt.monotone.test-deltas branch in the main monotone.ca repository for a test script and [sample output](http://matt.ucc.asn.au/monotone/delta-screenshot.txt). ## Size comparison for against-base deltas ============================================================ --- wiki/DocTodo.mdwn 88763ceb57e0b89c473abacc7e1d340ca2e233a0 +++ wiki/DocTodo.mdwn c231ae88a78c1e910e866e680ca975f59bceb5ed @@ -14,7 +14,7 @@ Some tasks for improvements to documents * 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 [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 pulling down an existing monotone-hosted project (like monotone's [self-hosting](http://monotone.ca/wiki/SelfHostingInfo/) 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) ============================================================ --- wiki/EssentialMonotone.mdwn cd9964973864ddd67c969a320601807cd56259ed +++ wiki/EssentialMonotone.mdwn 3ef3566cd8724e1f43fcb311d17dab0092a20b2c @@ -14,7 +14,7 @@ For read-only/"anonymous" tracking of an `mtn pull && monotone up`: pull latest source and update working copy - See [Self Hosting](http://venge.net/monotone/self-hosting.html) for further details on doing this for monotone itself. + See [Self Hosting](http://monotone.ca/wiki/SelfHostingInfo/) for further details on doing this for monotone itself. For contributing: ============================================================ --- wiki/FrontPage.mdwn d9895b4921626cd3a30727d854d14716307c4bf2 +++ wiki/FrontPage.mdwn 6b8c18a380c3806a8f3f6c977fdecad8f42324e6 @@ -1,7 +1,7 @@ [[!tag migration-wip]] # monotone wiki -This is the wiki for the version control system +This is the wiki for the version control system [monotone](http://monotone.ca/). monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. it understands history-sensitive merging, lightweight branches, integrated code review and 3rd party testing. it uses cryptographic version naming and client-side RSA certificates. it has good internationalization support, few external dependencies, and runs on unix, OSX, windows, and is licensed under the GNU GPL. @@ -32,13 +32,13 @@ a useful collection of brokenlinks at [[ ### Using Monotone * [[InterfacesFrontendsAndTools]] -- other programs that work with monotone * [[EssentialMonotone]] -- the minimal commands needed to get anything done - * [[AlternativeOverview]] -- a different order than the [Tutorial](http://venge.net/monotone/docs/Tutorial.html) for introducing monotone capabilites + * [[AlternativeOverview]] -- a different order than the [Tutorial](http://monotone.ca/docs/Tutorial.html) for introducing monotone capabilites * [[BestPractices]] -- best practices for using monotone * [[MasterRepository]] -- Master Repositories you might be used to with a centralised VCS, and why you don't need one with monotone. * [[MonotoneAndCVS]] -- different ways of working with CVS and monotone. * [[UsingCerts]] -- how certs work, and don't, in practice. * [[TrustFoundations]] -- the basics of monotone's trust model, and how it works with certs - * [[BranchAnalogy]] -- understanding how monotone's branches work, and might be different to other tools. + * [[BranchAnalogy]] -- understanding how monotone's branches work, and might be different to other tools. * [[BranchNamingConventions]] and [[BranchRenaming]] -- discussions about how to name your branches and what to do when you change your mind. * [[DaggyFixes]] -- handling bug fixes, backports, and cherry picking * [[TipsTricksScripts]] -- useful snippets for getting more out of monotone ============================================================ --- wiki/MasterRepository.mdwn dc92fc19c209321301f4b0f301bf48a55ed964e7 +++ wiki/MasterRepository.mdwn e79ae3babd27f47a8812cd105c34f214f6a685f2 @@ -19,7 +19,7 @@ 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 [Tutorial](http://venge.net/monotone/docs/Tutorial.html), we saw Jim set up such a server for his work +In the [Tutorial](http://monotone.ca/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. @@ -31,12 +31,12 @@ There are several things you might think important. 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. +copy to achieve, perhaps based on your established habits or expectations from other systems. 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? @@ -49,23 +49,23 @@ frequently, it doesn't contain any revis repository usually doesn't need to be backed up at all. Since nothing is committed locally on the server, and since people replicate with it frequently, it doesn't contain any revisions that ''aren't also -elsewhere'' in individual developers' databases. -Because all the revisions are signed, the same trust evaluations -can be applied to these revisions, even if they've been sent to +elsewhere'' in individual developers' databases. +Because all the revisions are signed, the same trust evaluations +can be applied to these revisions, even if they've been sent to 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). +revisions that were first put there by someone else). 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 again. Most people have a copy of most revisions, and for the very newest revisions that haven't propagated everywhere yet, everyone who -cares about these revisions has a copy, at least. We saw Jim take +cares about these revisions has a copy, at least. We saw Jim take advantage of exactly this property when setting up his server, in the tutorial. Of course, that shouldn't prevent you taking backups of the server's, or -your own, database as protection against the various gremlins that lurk +your own, database as protection against the various gremlins that lurk in dark places -- it just means that you can generally back up any of these databases pretty much interchangably for the same effect. @@ -99,11 +99,11 @@ any distributed system like monotone, an Many of these are just not really suited or even possible to centralise in any distributed system like monotone, and need to be addressed in -other, distributed ways. +other, distributed ways. Monotone has sophisticated trust evaluation mechanisms, using the information published in certs, that let each -person make their own decisions about who should be trusted to +person make their own decisions about who should be trusted to commit where, and how information will be used. Although very powerful, sometimes this is cumbersome to manage, @@ -114,13 +114,13 @@ those rules, for distributed enforcement authorities. Note that this will allow centralised publication of those rules, for distributed enforcement. -Monotone also has network access controls over who can copy information -out of, or into, a server - and again, no server is particular or -special. Everyone's database can be a server when needed. -If you have confidentiality concerns over the content, -you need to trust the people and protect the places that information is copied. -Once someone has a copy of some information, there's nothing in -particular you can do centrally to control where else the information +Monotone also has network access controls over who can copy information +out of, or into, a server - and again, no server is particular or +special. Everyone's database can be a server when needed. +If you have confidentiality concerns over the content, +you need to trust the people and protect the places that information is copied. +Once someone has a copy of some information, there's nothing in +particular you can do centrally to control where else the information can be copied, either with monotone or with other tools. Some of these things you either need to let go of and accept that the ============================================================ --- wiki/MonotoneOnDebian.mdwn df31c0ce9573084063ea3230cf17df3ac0ed8fd5 +++ wiki/MonotoneOnDebian.mdwn 149bd88130bca0538dca50b2b33b31ff0c1d4507 @@ -2,7 +2,7 @@ # Using Monotone on Debian -Monotone packages can currently be found in the Debian repositories. Monotone changes very rapidly and versions in sarge and etch may be slightly dated. It is recommend that you use the monotone package from the monotone [website](http://venge.net/monotone) or the version that is in sid/unstable which is generally kept up to date. +Monotone packages can currently be found in the Debian repositories. Monotone changes very rapidly and versions in sarge and etch may be slightly dated. It is recommend that you use the monotone package from the monotone [website](http://monotone.ca) or the version that is in sid/unstable which is generally kept up to date. apt-get install monotone ============================================================ --- wiki/MtnSummit/Ideas.mdwn a41f9445ec0aeb1c8f67e339b3e59dae31a9cfd4 +++ wiki/MtnSummit/Ideas.mdwn 661146eae05561ef01940a3884adb9a9780b478a @@ -76,7 +76,7 @@ Brainstorming ideas to be worked on at t * formatting support for automate * Rehaul the i18n stuff (right now, e.g., names from the file system are not translated correctly) * color each branch differently in ASCII-k - * monotone URIs, like mtn://venge.net/h:net.venge.monotone for push/pull/clone + * monotone URIs, like mtn://monotone.ca/h:net.venge.monotone for push/pull/clone ## Tools, Documentation, and other things @@ -86,7 +86,7 @@ Brainstorming ideas to be worked on at t * documentation and presentation tidyup * generation of manpage from internal docstrings (and possibly fleshing those out too) * sample monotonerc file? (possibly also available as monotonerc(5), etc.) - * merge_into_dir monontone dependencies (Botan, lua, etc) into net.venge.monotone + * merge_into_dir monontone dependencies (Botan, lua, etc) into net.venge.monotone * advocacy, promotion and tools to help OSS projects to switch to monotone Add more wishes! ============================================================ --- wiki/ProjectsUsingMonotone.mdwn e1ee6d4cbad720e3b4e3b5857bd7633a94e63e7f +++ wiki/ProjectsUsingMonotone.mdwn cc428fa8c5c1711318aa09a23918059b7a28b1f1 @@ -12,30 +12,30 @@ Project |notes |revisions |files |commit [[!table data=""" Project |notes |revisions |files |commits/month |First commit |Last update |Other projects in database | -[Xaraya](http://www.xaraya.com/) |1 |Â±33900|Â±58300| 552|2002-09-28|2007-10-14| +[Xaraya](http://www.xaraya.com/) |1 |Â±33900|Â±58300| 552|2002-09-28|2007-10-14| [OpenEmbedded](http://openembedded.org/) | |Â±23000|Â±14600| 754|2005-06-30|2008-01-30|[NSLU2-Linux](http://www.nslu2-linux.org/) -[Pidgin (formerly Gaim)](http://pidgin.im/) | |~23900| Â±6500| 250|2000-03-23|2008-01-30| -[monotone](http://venge.net/monotone) |2 |~13800| ~7740| 258|2003-09-04|2008-01-30|[Botan](http://botan.randombit.net/) -[Remobo](http://www.remobo.com/) | | Â±1415|Â±39445| ~30|2005-11-23|2008-03-16| -[I2P](http://www.i2p2.de/monotone.html) |7 | Â±4000| Â±6000|Â±100|2004-04-08|2008-10-27| -[Trig](http://trig.com/) |3 | Â±7948| Â±2995|Â±637|2006-05-09|2007-01-30| +[Pidgin (formerly Gaim)](http://pidgin.im/) | |~23900| Â±6500| 250|2000-03-23|2008-01-30| +[monotone](http://monotone.ca) |2 |~13800| ~7740| 258|2003-09-04|2008-01-30|[Botan](http://botan.randombit.net/) +[Remobo](http://www.remobo.com/) | | Â±1415|Â±39445| ~30|2005-11-23|2008-03-16| +[I2P](http://www.i2p2.de/monotone.html) |7 | Â±4000| Â±6000|Â±100|2004-04-08|2008-10-27| +[Trig](http://trig.com/) |3 | Â±7948| Â±2995|Â±637|2006-05-09|2007-01-30| [ConquerSpace](http://www.conquer-space.net/) | | 2392| 4449| ~88|2005-11-26|2008-01-30|private projects (total ~6717 revisions) [Ada-France](http://www.ada-france.org/article130.html) | | ~1390| ~1270| 74|2006-07-14|2008-01-30|[Lovelace OS](http://www.lovelace.fr/) -[GoTT](http://gott.evilhackerdu.de/) | | Â±1716| Â±800|Â±100|2005-07-08|2007-01-13| +[GoTT](http://gott.evilhackerdu.de/) | | Â±1716| Â±800|Â±100|2005-07-08|2007-01-13| [Ajisai](http://www.randombit.net/projects/ajisai/monotone.html) |2 | 770| 1118| 45|2006-05-18|2007-10-14|[Botan](http://botan.randombit.net/) -[Syndie](http://syndie.i2p2.de/monotone_howto.html) |8 | 676| 696| 55|2006-10-12|2007-10-14| -[PacketFence](http://www.packetfence.org/) | | 514| 564| 80|2006-10-02|2008-06-17| -[ATF](http://www.NetBSD.org/~jmmv/atf/) | | 504| 409| Â±60|2007-06-25|2008-02-06| -[Dropbear SSH](http://matt.ucc.asn.au/dropbear/) | | Â±250| Â±600| few| | | -[guitone](http://guitone.thomaskeller.biz) |2 | 640| 214| 30|2006-04-06|2008-01-30| -[CTWM](http://ctwm.free.lp.se) | | Â±300| Â±350|low traffic| | | -[Pantomime](http://www.collaboration-world.com/pantomime/) and [GNUMail](http://www.collaboration-world.com/gnumail/)| | 150| 781| 8|2006-04-29|2007-10-14| -[Bonsai](http://www.bonsai.com/wiki/index.php/Monotone_Distributed_Version_Control) |2,5| 87 | 398 | 4|2005-12-18|2007-10-23| -[MetaTheme](http://www.metatheme.org/development.php) | | ? | ? | ? | |2006-09-26| -[Clarens](http://clarens.sourceforge.net) |4 | ? | ? | ? |2005-08-09|2006-12-13| -[NetCrypto](http://www.netcrypto.org/index-FileAccess.html) | | ? | ? | ? |? |? | -[Peter Todd's Art Projects](http://petertodd.org/art/source-code) | | Â±1500| ? |Â±100|2007-05-01|2007-09-09| -[Neurospaces](http://www.neurospaces.org/) |6 | Â±2000| Â±2000| Â±30|2006-09-07|2008-10-14| +[Syndie](http://syndie.i2p2.de/monotone_howto.html) |8 | 676| 696| 55|2006-10-12|2007-10-14| +[PacketFence](http://www.packetfence.org/) | | 514| 564| 80|2006-10-02|2008-06-17| +[ATF](http://www.NetBSD.org/~jmmv/atf/) | | 504| 409| Â±60|2007-06-25|2008-02-06| +[Dropbear SSH](http://matt.ucc.asn.au/dropbear/) | | Â±250| Â±600| few| | | +[guitone](http://guitone.thomaskeller.biz) |2 | 640| 214| 30|2006-04-06|2008-01-30| +[CTWM](http://ctwm.free.lp.se) | | Â±300| Â±350|low traffic| | | +[Pantomime](http://www.collaboration-world.com/pantomime/) and [GNUMail](http://www.collaboration-world.com/gnumail/)| | 150| 781| 8|2006-04-29|2007-10-14| +[Bonsai](http://www.bonsai.com/wiki/index.php/Monotone_Distributed_Version_Control) |2,5| 87 | 398 | 4|2005-12-18|2007-10-23| +[MetaTheme](http://www.metatheme.org/development.php) | | ? | ? | ? | |2006-09-26| +[Clarens](http://clarens.sourceforge.net) |4 | ? | ? | ? |2005-08-09|2006-12-13| +[NetCrypto](http://www.netcrypto.org/index-FileAccess.html) | | ? | ? | ? |? |? | +[Peter Todd's Art Projects](http://petertodd.org/art/source-code) | | Â±1500| ? |Â±100|2007-05-01|2007-09-09| +[Neurospaces](http://www.neurospaces.org/) |6 | Â±2000| Â±2000| Â±30|2006-09-07|2008-10-14| """ ]] Notes: ============================================================ --- wiki/SurveyQuestions.mdwn a3ec3be0f6f9978e3e0e8ca2930ece94cb193c05 +++ wiki/SurveyQuestions.mdwn abaad1f980b02c19cf53af735ed2b412a9652836 @@ -41,7 +41,7 @@ Questions we should consider asking the * How much memory and CPU speed do the machine(s) you normally run monotone on have? - * Where do you get your monotone binaries? (E.g., by downloading source from venge.net, from the binary downloads on venge.net, from a distribution (if so, which?), etc.) + * Where do you get your monotone binaries? (E.g., by downloading source from monotone.ca, from the binary downloads on monotone.ca, from a distribution (if so, which?), etc.) * Do you use inodeprints? Do you know that inodeprints exists? ============================================================ --- wiki/ikiwiki_migration.mdwn 92016357fffd2c431959c95bb8ad3402c3ae37f4 +++ wiki/ikiwiki_migration.mdwn 489f79fa259fce5b5c02a6ad7cf4f97b23b9e03c @@ -4,6 +4,8 @@ 1. fetch the page you're going to migrat markup style, into the workspace, and commit it as is for reference. (adjust as needed for some other tool, like wget or curl). + ATTENTION: The moinmoin wiki was shutdown on 2008-12-16, so this no longer works + ftp -o ZipperMerge.moin "http://www.venge.net/mtn-wiki/ZipperMerge?action=raw" mtn add ZipperMerge.moin mtn commit @@ -43,7 +45,7 @@ 3. Translate the markup. *Some of this m of single-quotes * Links are done with `\[[SquareBrackets]]` rather than bare - `[[CamelCaseWords]]` + `[[CamelCaseWords]]` * preformatted code blocks are done with 4 more spaces (inside the current level of indentation, say when inside nested lists), @@ -53,7 +55,7 @@ 3. Translate the markup. *Some of this m rather than `[http://url link text]` An exception: when the URL is the link text as well, it can be - simplified like this: `` + simplified like this: `` The angle brackets are *required* in this case. Ikiwiki and markdown do not make any attempt to interpret URLs otherwise.