# # # patch "wiki/AttrUseCases.mdwn" # from [28ad729b1a091fd2bfcbf8b6aecf33bcbc19a010] # to [f2cc0b7ca01630f8a52a942f239e55a5f1588e17] # # patch "wiki/AutoInodeprints.mdwn" # from [34e2067b3a72045144df0d3519db3b23ac0851cc] # to [ec0a46f34f1667d72990daf7c41c8b94cdd10e90] # # patch "wiki/AutomateMagic.mdwn" # from [9906e2fadd6fe925a4d0bf5ea413ea74ec491cc8] # to [7a695ff7ff2d715c6213aba46ef22b3875c0f939] # # patch "wiki/AutomateVersions.mdwn" # from [4b8e9e7df7890ae77715d6f6f359eb32289906c3] # to [15822ad5346f8e37cb309b257d4c8440e93c30d4] # # patch "wiki/AutomateWishlist.mdwn" # from [9e60a86c160b796410ad0dcbcb512bfe294bc090] # to [f7b59a5dded365db4f96f16bf59c50640fd8fb10] # # patch "wiki/BasicIoFormalization.mdwn" # from [1a03eedc6b863debf07faf3103201420327e6d5c] # to [8a455aa003507af81235b7249aeaba12456e6a72] # # patch "wiki/BestPractices.mdwn" # from [2e172c2d23098a8623f44ea8a1a67db550a695ab] # to [77bdf298eec6178b238eb1b928b1d46f521feeb7] # # patch "wiki/BranchAnalogy.mdwn" # from [cc8a4bfd82b69aa080a21a7241208c6141307cda] # to [b1ca76dbc0b42416e650a28757cbb2f1e38daeba] # # patch "wiki/BranchNamingConventions.mdwn" # from [195f41472ac53cb719e713fc95140febc5c1ccdd] # to [889e9077c9e48673ed6c07f05cff4f1d8951e6fd] # # patch "wiki/BranchRenaming.mdwn" # from [b8db5634de32b04faa1fbc0a90b3a7d0d6675e0b] # to [c8267fda96f52892e816c8968bbd85ea72af55da] # # patch "wiki/BranchStatuses.mdwn" # from [3a294c70d9cc293ad71216673176a8b8e46bb793] # to [b88e30c47c2dc26d5d23b35ce1c19ec6dcb9f810] # # patch "wiki/BranchUI.mdwn" # from [880da7619aff3fb0e3683611f80cb784502774c6] # to [5c6fa2d2017409b16e73475da283bf176acba657] # # patch "wiki/BugSquashingParty.mdwn" # from [9fc823e6825667b2d40881fe08c01d3330cd6b67] # to [5a747c42940290dc5c0db8e42be4cefe0ce5d23f] # # patch "wiki/BuildBot.mdwn" # from [100b7b92675080b560373def21c47a846a80039d] # to [d4c2817a00e59d679731b11bcaaedc48c478f886] # # patch "wiki/BuildingOnMac.mdwn" # from [cbec17ebfa915d864e1b1c79d830e760c4e795c1] # to [4f0de7c334ec8b597117edad21950d8e4835bd09] # # patch "wiki/BuildingOnSolaris.mdwn" # from [c8bfbc121048baa94dc5d7a6f808fe9a30d533f3] # to [ec5f4fc37090aee0c79bb06e0f74d6902c138d4b] # # patch "wiki/BuildingOnWindows/VC8.mdwn" # from [bdd4f56d523bc78d3e5a377140ab3aaf7d629f6a] # to [1bf81a149149a34c67a4122be1693b5fdece1b8d] # # patch "wiki/BuildingOnWindows/VisualC8.mdwn" # from [bdbfab37f2165a12c375a5aa4dce84077e6a43cf] # to [76798f508e9c80417ba72fb7bfd73403b94a7634] # # patch "wiki/BuildingViaPkgsrc.mdwn" # from [d2a5a7207282a2b62df155cfe6916250faa52b47] # to [907e3c4997271b97bd76e537f5047576e9e91536] # # patch "wiki/CarrotAndStick.mdwn" # from [dd68135ee164e40b236eabafd71a9d4b9702d511] # to [c46bbeb49ce1014c7bf4b4711dae38321d0f8e92] # # patch "wiki/CaseInsensitiveFilesystems.mdwn" # from [399c68b79dd983fa10befc1f14d63b6e9cd67696] # to [775d3ce9d7dbbace6e09a504dbf733803bef2fbd] # # patch "wiki/CertCleanup.mdwn" # from [c719e5fe06aab7d1b9c58e1aee6528573f6b69c1] # to [860f798a0396949199f247d60702336f30b88e5f] # # patch "wiki/ChadWalstrom.mdwn" # from [d5766ac6ec33842ae18443b6cc37ae5dae8b093a] # to [9cb1551ef351465a9a0b037580a974675ac40191] # # patch "wiki/ChangeLog.mdwn" # from [a41c6e2186c7baf99020cb9ec77d639d1f573b1c] # to [b851c0c5dacdb0ba1cc9c4afe3c3a33fba319128] # # patch "wiki/CherryPicking.mdwn" # from [02db5fd6b04b151328347871f745a57dd7259713] # to [35c13a05b12ed721682eb28d86312db13f649efc] # # patch "wiki/ChristofPetig.mdwn" # from [68bfdf45f079aca4a14eff4e883a9448b770b367] # to [c9bc104754ff7756e98d2ce4691224d2201b6cf0] # # patch "wiki/CraigLennox.mdwn" # from [0d58a96602111ae00ab7dae7fa6c4b1c68ca8ffd] # to [f06ae2e40410ef0d65816d5f76e5861db5fea2f4] # # patch "wiki/CreatingBranches.mdwn" # from [b1f7c9b4e653c3dfda3fbf2e83ac428f8792f0f5] # to [f16ff2700744b1edcf973cdb35b55ecd195881f2] # # patch "wiki/CvsImport.mdwn" # from [4ce058f21673400073d7007b050cff953342aa90] # to [36b58350740c8982cb1b07a2267b5eefd0688a11] # # patch "wiki/CvsSync.mdwn" # from [92804911fad04a6f54fa3c3eafd8e46ecdd729a2] # to [aeae341030e253f2ca05f240b0b1f1a891918e2c] # # patch "wiki/CvsSync3.mdwn" # from [73333f0252e0c030af2a6d7ac44108c199989e3b] # to [35b1730ef42e0671cd21ee6832bc329f9de35226] # # patch "wiki/DagBasedRefinement.mdwn" # from [12853aa0f5827d4b57db17d7c60130296f808027] # to [8c7c7619b63fa5f0d05b746ad1a22a1e40fcf727] # # patch "wiki/DaggyFixes.mdwn" # from [1f2136f48e8ec7e2a152b4c037ada0f029670a83] # to [4f96fcfd13ff0cb7e2c3cdd7ae058dab467e8672] # # patch "wiki/DatabaseLocking.mdwn" # from [4de6bde9707ce9f70e2961118222959bb01c1af4] # to [c2e334f09b21115db6cf3a0ce6262b5f84576dbe] # # patch "wiki/DeltaStorageStrategies/ShootOut.mdwn" # from [6f52fe1f30481dce1482e63225e8ea2066b9cee5] # to [c5ae1c718327b7cceaf63112bd5f5fac5a3219d9] # # patch "wiki/DeltaStorageStrategies.mdwn" # from [d798bb1c080834f4d9f15a5f5a30d4f9f077769d] # to [9a0188f708cf39a7c55e8f816a60db26d2960744] # # patch "wiki/DerekScherger.mdwn" # from [7c23559593fcc0b960f0a6af6ce6a4f0e7371b5a] # to [8231dd334d3a3c56a9e5e635bd7c23f0cc0f13e0] # # patch "wiki/DevGroup.mdwn" # from [0aa37b3c943fd9489bae7d72a5e7b5364076f178] # to [44cbac762fe960037d5a0ab4d10039b3ae35f8c6] # # patch "wiki/EmileSnyder.mdwn" # from [aa9316ddc5d5b96ce1bb42a4b1fa97da566938d5] # to [cea9a1ea3cce40b6b21f928c6bf52a107fbfd52b] # # patch "wiki/EssentialMonotone.mdwn" # from [faf145c09aed47b366d630a5c00f4e3b016322fd] # to [e47245d221a6d8afc661e733e940e2fa2655604e] # # patch "wiki/Feature/AccessControl.mdwn" # from [602447a5122d82a14117f80dfdf3a1e89f5551cb] # to [23630975ba047e00ca4d718ae191f0306119d5f1] # # patch "wiki/Feature/AtomicCommit.mdwn" # from [25ad516ced4862d86105b75d4ec61c49effc9a19] # to [d6f957b72af66fd140e05cf6d634546b81986750] # # patch "wiki/Feature/BuildIntegration.mdwn" # from [be9278519c0ab85a38f369d6870d40fa34b967f6] # to [36bbc941f66e054108f83bc1678a834e18ee146e] # # patch "wiki/Feature/CVSExport.mdwn" # from [df4ff494269e75202d77a795b5e2e68342bafc6a] # to [0d107390d040be02a22f3407ab7a427a31dc05c5] # # patch "wiki/Feature/CVSImport.mdwn" # from [5c6300c9fe93bb2590b185e4444478c09a1c7a80] # to [e4c82c358adee251cc2925d6a6443a6ec7bc028a] # # patch "wiki/Feature/CommitMail.mdwn" # from [67ec4dcec228783fc0eb8b18a14be89f7c3c1c38] # to [895c8d7544d1a271a13a2d1a160e69b350414cb3] # # patch "wiki/Feature/CompactRepository.mdwn" # from [98b623ce12da9e23ac4543f5baaedf73a76706e9] # to [43e51184ebc4660a7a6e12a2191a3c8de23931b8] # # patch "wiki/Feature/EmbeddedIDs.mdwn" # from [b1dd19db90df9c62f18d6a979fd84e4a82f825f0] # to [2fb64ae787892c98f500e1bc0dbf9e035a0ec194] # # patch "wiki/Feature/Fast.mdwn" # from [30efd1cd6f42c4b0580efc513d21463a04b0ae79] # to [e75bb1e1aec583f45fa9bb0a086ad82a12bde0b8] # # patch "wiki/Feature/LightweightBranches.mdwn" # from [d8ec536deeb0f29e7f83d8ce4791fe28ca0f0b78] # to [04a8621513880ef88129ded11167a2040ee781ed] # # patch "wiki/Feature/LogReview.mdwn" # from [47bdd8f9d66eafa14c1e8bdb822d7e3ac89369f9] # to [a5c264c46039a06658e179a60ae5ed112fb519d2] # # patch "wiki/Feature/LogTemplates.mdwn" # from [ff0d39741e3af68270d6f66c6dbe0020eb6d7ffc] # to [f1ceb981deab3f53450d28a5fb7f3d4750c7de03] # # patch "wiki/Feature/MIMEtypes.mdwn" # from [5eac1573212dcdd39fa83463c58ef13b3a347566] # to [c9acd4b2de1d8031a47d51e8b838925f3025922c] # # patch "wiki/Feature/Merging.mdwn" # from [16325f0f42a0b0e20fe053f9dfefc3cdb84ae8e8] # to [ef54056003a95437815e95e03c990e4c54772eb2] # # patch "wiki/Feature/Mirroring.mdwn" # from [e9fec1d6599111682bca5a82346d9957c16719fd] # to [80e9511b3332f2fc66cab018bf6a740c96380ecf] # # patch "wiki/Feature/NetworkSecurity.mdwn" # from [d2d1cb04c0b62e3594ee5b8173c341f49f05eba9] # to [ac5939ceb9a3919fad1e7e33ce60c8dbe6c2b17b] # # patch "wiki/Feature/Obliterate.mdwn" # from [94388e7338b7d632fa402748e96105bbeaff001d] # to [15c2166ae0fbb021452c4f9c93f847be891792df] # # patch "wiki/Feature/Offline.mdwn" # from [cf75aa0a5f61a7f29a62f527f5a0edf0b5f65093] # to [56f350439566a7611c36a24785346487d9118679] # # patch "wiki/Feature/Portable.mdwn" # from [8e869a5838741208c3ab03e3eacdc503f3113ae6] # to [cc39429eec037bca0c1c507ce2565d07a3c018a5] # # patch "wiki/Feature/Rename.mdwn" # from [6c7fd056de73915f8df7438bfcdab69cf6ceee06] # to [ffeb9e545140e5741a9a9643b393fac617ab4397] # # patch "wiki/Feature/RobustRepository.mdwn" # from [95cf48aeded395db8848c15993dcf85cafbd0f46] # to [6afeb7ac2704cb02cee1b50227610af6530f8f42] # # patch "wiki/Feature/SignedRevisions.mdwn" # from [39be6532825e0c03545be5263107e5c717ba10f0] # to [90c9f380491d7e64bbfb2258e7aa447088a3f97d] # # patch "wiki/Feature/Symlinks.mdwn" # from [eff0776f2e133f6b6869957af5d901cea120f2b3] # to [88548ea4b993680e83b5cf63b6a080427b36fa63] # # patch "wiki/Feature/VendorBranches.mdwn" # from [784aad745e2bfce39b6786e3f8b55fa5c8332787] # to [76392bfc752e1a954ec9ea0092749b6c9c5e42b9] # # patch "wiki/Feature/WebInterface.mdwn" # from [ea021a1a917c9a8e8b59fded3a64b796e5acd308] # to [21cbac8e32b740bfe52d483b598798e02e93ad0a] # # patch "wiki/FileSystemIssues.mdwn" # from [f9d34b769014225c5eadde10398f3f54a2b7fd9c] # to [fe5294d625288eca796ac795f297f174e8bcd2ba] # # patch "wiki/ForSide.mdwn" # from [49224ef964b59238b37bfd0d54e05684efd0356a] # to [41936623f8280c15db6c99f3272fc283b65196ca] # # patch "wiki/FutureCryptography.mdwn" # from [1357ffb4527c1b5530654216fc0a533811a83c92] # to [e0956367d8b0df160095f502944cd7c5d7a3cb5a] # # patch "wiki/Glossary.mdwn" # from [8169c5e85885d58a63b8a72075f53058d9994766] # to [4a99fba88b0ce5b5a1a0d47750da612408d5b6fc] # # patch "wiki/HistoryBlueSky.mdwn" # from [3a5e4b3e848dde314aead126826edb1ea5ac0946] # to [6a7f857e0bb6c7f93304f87193502b5b21b935e3] # # patch "wiki/Hosting.mdwn" # from [ab94b4fbf8ced47002785e3ab1cca6c0af890454] # to [bb7585a980381403debc0a2496f02ecd320dc00c] # # patch "wiki/HugoMills.mdwn" # from [8b3526ec529983a4ea155558039e70b7fd34807e] # to [62d487fcfcf7261f01a9726a73e5a0fb1d486566] # # patch "wiki/I18nL10n.mdwn" # from [fcf0b74f76b8f4650f020908d54ad1a442400498] # to [0624dc000a16fd4820948e47b57e52aee17883e2] # # patch "wiki/IPv6.mdwn" # from [48a6666b21c8508128dc100665415a0d50bc1e59] # to [ef6ced3d38224102acbbd57855b2de9c9f78cfb6] # # patch "wiki/InterfacesFrontendsAndTools.mdwn" # from [b65d58e509145238f09d29dc6a4e13b54e7ef2f4] # to [5388646c831aef3b47914eacd1a5129a10fdbcc2] # # patch "wiki/JackLloyd.mdwn" # from [9654fecf50faebb942c1011b23edc95ae9d858a6] # to [2191ace805acbc85f332c9b91af5c83c8aa75d1e] # # patch "wiki/JustinPatrin.mdwn" # from [5bdcd4e7827982a4e5fd5d2eabb8b586239cc922] # to [89ce1745824b310863352dbb392a2b233b77076a] # # patch "wiki/KeystoreFiles.mdwn" # from [c0d87637f7942b10723c16d4faa1abfb072a6b54] # to [ff51712317ad6d9293ce35852026398a6ea05ff2] # # patch "wiki/LineEndingMunging.mdwn" # from [ec36aadccee4809958f37b1fd85c90c7dddade4d] # to [37fadeba70b04e9770e60772cb7351b2904378e8] # # patch "wiki/LocalBadContent.mdwn" # from [6f76d0887b4acdb08b596b78d5aae5fbc38f93f0] # to [6b1921231e819ec2627ed6dce8a72e196a266cb6] # # patch "wiki/LocalSpellingWords.mdwn" # from [c33eefbf5615908da497b48b5397c500f698e7d2] # to [2b646abd5c12ce04fd5ac2e2055369702caa04ed] # # patch "wiki/LogUI.mdwn" # from [d9bc2405923542fb7aead5e99d3dce94920f0c51] # to [36a55a58ea5aa67436dcd3065a6fc3202045480a] # # patch "wiki/MagicSelectors.mdwn" # from [5903cb1b9ac1d4ca7fa4c6aaeace4c297e08a50e] # to [f9c4f0efd03785edbe2447673adba1775c80665e] # # patch "wiki/MarcelvanderBoom.mdwn" # from [63df608c4a0b952d19c7773593839904833c8891] # to [0dfcfa8a07ff7b80ccf0ed269966c2a80ed97aba] # # patch "wiki/MarkusSchiltknecht.mdwn" # from [f31820b08fec94a20c7488ae7e111f013d491a7e] # to [26854b32cd94cd7bf4408e37d618a926608c126e] # # patch "wiki/MattJohnston.mdwn" # from [bcb146694deff01d56d3879b66b7b2bccac72e64] # to [f1caf9c86542b014ae3618e3271fa7eae94f23c0] # # patch "wiki/MergeViaWorkingDir.mdwn" # from [e514b5c7f268cf67c004f9303d035779014a8032] # to [846e01b7dc491e4aa3e7d6712c6f3a70e616c356] # # patch "wiki/MonotoneAndCVS.mdwn" # from [cad35e67ad8d80db34b1b091a01d7d093aa92179] # to [4bc49653a62efc5259d46a7aec973772e90be20d] # # patch "wiki/MonotoneOnDebian.mdwn" # from [0ac72fcc707cac862c04cef732b080ee54eba3f8] # to [8929087ed6c41902a42ac46707359a2ab3fab0e0] # # patch "wiki/MtnSummit/2007/AsciikReview.mdwn" # from [b53c26b9b646216fb1cce573c9fea3d8648eed22] # to [e3b3b96193b944245d3abb1f96056677a04601fd] # # patch "wiki/MtnSummit/2007/Funding.mdwn" # from [e9d1a4c25cf2417ba32e2e2fa244bc501b601f16] # to [2834c6d8a1b5b2097558f0a0d22e1fef3991d8d1] # # patch "wiki/MtnSummit/2007/Gibberish.mdwn" # from [26238ad7803129af272a0a085cadab948b9164e0] # to [5ea8995dcbd984c719d21e86934329f6ae74beb5] # # patch "wiki/MtnSummit/2007/Ideas.mdwn" # from [06e80157712ceef45bd1e3f8d70e502386f8bb95] # to [56a30d0bc0a02a5231e027a1f798003a84d3c481] # # patch "wiki/MtnSummit/2007/InterestAndDates.mdwn" # from [13ed055222d9e31afaa81d9ec3fae360b082bb7e] # to [ecb464dede872abda0e0de3e433c87053f5d159f] # # patch "wiki/MtnSummit/2007/LogisticsNA.mdwn" # from [795773c41d1565600c9df1fc74571d8e3592cd32] # to [05a41595687f8306615af40a1f41e94191b5de4a] # # patch "wiki/MtnSummit/2007/Notes.mdwn" # from [40c33a59e74d92b7ae791bc409aa2685ceeb42a4] # to [e033091476473292369f982386811109c6d3da33] # # patch "wiki/MtnSummit/2007/Rooms.mdwn" # from [33c00fccf312d672d9c9fb44dfc81f257390fba6] # to [37a4e4e4b7ab06e3e060e49beafc616b46bf7d37] # # patch "wiki/MtnSummit/2007/Schedule.mdwn" # from [cbbb9e357a270bf8e0e2e1d89524aa37daaba4e9] # to [917925aa0747cfd410716067e6e5fc2e41e0df69] # # patch "wiki/MtnSummit/2007.mdwn" # from [f1044e55b7e35a0462c84a2305cf3fea1066fb12] # to [2ec19cb36538dc5e0c4ddc54bcf5debb19598c5f] # # patch "wiki/MtnSummit/2008/Branches.mdwn" # from [4624d81fad4a17d69424573f0263c9ee561a111b] # to [b1ea00060a74dbac4f14a7e793f343620b77bd69] # # patch "wiki/MtnSummit/2008.mdwn" # from [b81793864edb6e40c98b755ef468441ca81b03a5] # to [b343ea00bb3abe4cc9e26931268d8a8c2fdd4d4b] # # patch "wiki/MtnSummitWishes.mdwn" # from [6091a916665165d609749b049a469e4aea45a01d] # to [431e08e0daefac95070a81da9a88ffe1b49f92ad] # # patch "wiki/MultiParentWorkspaceFallout.mdwn" # from [b6c941ff593277e86d44fb76704882196cdaabd2] # to [8aaecede2b97e136135d5a710e8f80554b0930b9] # # patch "wiki/NonMergeConflicts.mdwn" # from [236af559f86750d19177f0caca3304bfae6ca5ff] # to [8ade4ea021be0dcb1159f1d712cac552ea4f522e] # # patch "wiki/NotesOnTestingChangesetify.mdwn" # from [3d921d92e8493522c57302360e9154b766ac4ee0] # to [97c77d96cf528356e24485755aada4d62726b2ed] # # patch "wiki/OldTestHarnessIssues.mdwn" # from [ae22459256e7946bf5b746c6f5eba6c8fa0ea748] # to [0f26c25d30e5e3d2e48267658b965cf0f798b912] # # patch "wiki/OneBranchPerDbForServe.mdwn" # from [1a067c2618da87eee77e03d0b89446bd6cb45ccc] # to [d029b6ab0516bb8afd2353d7d0e27bde59389f89] # # patch "wiki/PartialPull.mdwn" # from [f88802944b7ca0efc5be21471a92712e74f1a81e] # to [8a3513572c00a6088f14acab5921316c97cfa83f] # # patch "wiki/PaulCrowley.mdwn" # from [0946669a557a94542bb3b3e599d10620ac56d707] # to [af2f3f4c0f52612fab89e4cbf7c46f07f964f97e] # # patch "wiki/People.mdwn" # from [6c9ec129ad4cf8e304b07e123668899e685101eb] # to [1b7c67dfcf9c40a48a8a5f82250cb2636bad0210] # # patch "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn" # from [43f9b4893ad690d7ffe613a73504241af1a01906] # to [1426d71fba4f82d540913ca2264c7007c9ac1e1b] # # patch "wiki/PerformanceWork.mdwn" # from [7734b29157885158904bdacc0e9651a5f3d97736] # to [6dc38f35ed590ab003cafc53a76c7cc892ec6bad] # # patch "wiki/PieceCache.mdwn" # from [ba54ba6fc2223670fce9e77761b5b00fd7f71f6c] # to [b5302dfae430e0cd4e135a60977f7811714c462b] # # patch "wiki/ProjectsUsingMonotone.mdwn" # from [acdda58a620edaa6fe2f74aa6cee4e32f3b612ea] # to [ebbb7ea394c1e6d772c3fcf2a74ccdcd6e54ad04] # # patch "wiki/QuickieTasks.mdwn" # from [61c008a59f664e98a3a8d533fc5f1db70f4a7683] # to [04d9663c47a897fcb46839834e65c9ecbb062c6d] # # patch "wiki/RelativePathnames.mdwn" # from [692ce2f3610ebf2be4dce521dd9d0a99da937811] # to [510d6366539b3ee80ed8724ef66959404b09252d] # # patch "wiki/ReleaseBranchPattern.mdwn" # from [7da38dacfada27acb510147207fefc0b0c30979c] # to [bfd999cc20436a9d65f7db08195f6ff92c99f70c] # # patch "wiki/RevertUI.mdwn" # from [43e2d1517696a780ae13fac22f9d83be1e9aa8ff] # to [e042b4274b04fa6aeb6b914b099be99927bc4b84] # # patch "wiki/RevisionNumbering.mdwn" # from [f7700c3a50756659f82c390f36735b53322957cc] # to [2bc8e462f05949afbd96bd3a57f995b9efeec8b0] # # patch "wiki/RichardLevitte.mdwn" # from [dd9737b8d84151c6ffc30a8c32c8b64a65aa4308] # to [ab2a758cd6af68f87dac4c1b954aa0efd1e75758] # # patch "wiki/RosterifyingPrivateBranches.mdwn" # from [2c7862562db525da61da21cfafa4e2a2e237efd3] # to [ca720d8bde285c834530d884620429709b940387] # # patch "wiki/RostersTodo/MarkAndMergeTests.mdwn" # from [47431f5846feb1de1d858e3de9b2f2562ba37692] # to [8f1ec9507ba518c975bfe95575f959f5c8e6b60d] # # patch "wiki/RostersTodo.mdwn" # from [7e1b6812218d5b4c4e42f6dbf2bc4e9cb707dee8] # to [ea7ef1c59b83a921aa2fe48c0e2a1bc892fa4353] # # patch "wiki/RunDbCheckOften.mdwn" # from [f7af58f53ee78780106d25bd9fb7ff7fda9ce9fe] # to [7a46c59576a7301dc2cfebf716f0e33c353c8ae1] # # patch "wiki/SelfHostingInfo.mdwn" # from [bc7b5317d5d1c5d4ddefb163bdfa6b0f57316e21] # to [0bd746560d51f83fc739d41ec4b816c586a6f9ec] # # patch "wiki/SimplerIgnoreMechanism.mdwn" # from [c971fde4098e05adbe6a9578b8a14afab4105614] # to [9b70cc3c5555e02181774c97ebf0ee7b3d5f3600] # # patch "wiki/SummerOfCode2006.mdwn" # from [f3665aae3c146e38e1833e9acd910f8bdc7a2f70] # to [b1bfb84a435af276201548c8dea336ce61de7ce9] # # patch "wiki/SummerOfCode2007/Ideas.mdwn" # from [44400155e32c63c4c25534627d4705befde093a1] # to [c3b1629627bb2c4b53b300247844424daf136b08] # # patch "wiki/SurveyQuestions.mdwn" # from [76c3e7e63bd23b880188c1665796973fded43b94] # to [9823b1bd2b1a927c2498d21335df05143080f9da] # # patch "wiki/SymLinks.mdwn" # from [c6f2f9ac598df17b4faeaf5719d67e8c96be78dc] # to [6f35d8ff05e9abba8196f38e807ce5dff8a8f5b0] # # patch "wiki/TestHarnessIssues/CleanUpTestNames.mdwn" # from [224a575278150618ca9e4537fdd65c50eb71b790] # to [3e1734e7d95aef7d8d001d4b118faf8675ad2b95] # # patch "wiki/TestHarnessIssues.mdwn" # from [cd865a57ddec6412baaee48518e46b784fa9bd15] # to [05c25c6aa0ba0ea83e6aa88e69153fc7618d72b4] # # patch "wiki/TestIntro.mdwn" # from [0a446eba96abbb8271437c6e4423fa81c31f2c9e] # to [1ebb177653074db535d275b8dc4ea30fceb97470] # # patch "wiki/Testimonials.mdwn" # from [ad20718e98e822c82420cab1fa2e7cffbc5f77ef] # to [4db5ee497000e3f789a7aa69991182db4feb1d8a] # # patch "wiki/ThomasKeller.mdwn" # from [d1df025099028c003ea447c33f10bc1e18e55a27] # to [720db157586e31c6e37e7a2fe1d99875dbb23b1d] # # patch "wiki/TimeStamps.mdwn" # from [8f01f494d6652eb13890b1e5a8600d72f4431fc6] # to [be17b9be314458640aecf493723951158bbae57e] # # patch "wiki/TroubleShooting.mdwn" # from [dd0c558677b450638a549cebe6fe1bdeefa55590] # to [4d2a8178e106f2cdb29181ca8995b062c0d90da5] # # patch "wiki/TrustDiscussion.mdwn" # from [8d061a5131141634b11423dc036cd1312f6623ba] # to [f7609f50afa7c1f782de89d9a9ccf54374104d8d] # # patch "wiki/TrustFoundations.mdwn" # from [5140b4eb879188c430b4a035a9da03847b071e58] # to [f5c91b8bb0fed349fd86e78e5d877b848b3bef96] # # patch "wiki/User:Metaeducation.mdwn" # from [52a6f318a1d28a595b0ce4b932859253c49d76ea] # to [3b8a931635cedf8acafed6529886654234c4ffe4] # # patch "wiki/UsingCerts.mdwn" # from [085555165f627f23025f5cae8129fbe5311662ab] # to [1946c79d5950ca510d1b14527ed2b1447f65dd2e] # # patch "wiki/VendorBranchPattern.mdwn" # from [05f7dfd5053b36427c582d17d8bb5354d68a2dd8] # to [0016658f5d17ec1ddb630a332ef84b6ef47ffe88] # # patch "wiki/VersionedPolicy/Archive.mdwn" # from [d941eeed55f2d7f53ae7c8695a07b6fd8832fa78] # to [e8c312c320ccb7da29502a0c99a4cdf5823ab7bd] # # patch "wiki/VersionedPolicy/Comparison.mdwn" # from [ec92935d6cf41883ceea13405adee556698529d2] # to [83f55131514dd6ca2236cedc6265cf3e35871188] # # patch "wiki/VersionedPolicy/Graydon.mdwn" # from [d63cacc1f3c72d94de7561d5287b85e29bb525b7] # to [414a99b3b45a56dfe60ea9b726d8bc35fc4139b2] # # patch "wiki/VersionedPolicy/Interface.mdwn" # from [11ac080bbd6d4bf8a8185d74202054ed87ce989f] # to [b183b345a8914fcc038df0f832cb2e3fed378946] # # patch "wiki/VersionedPolicy/SPKIWontWork.mdwn" # from [68582b766843abead050655fc766a9701eae3102] # to [7a610b3680f75c5c196a68cc86729615e888b212] # # patch "wiki/VersionedPolicy/WorkList.mdwn" # from [9e72f901ac8ce1b12d301023bfc63ff1ae833dd7] # to [c7d3119140422ab4962e591812de3da448715b81] # # patch "wiki/VersionedPolicy.mdwn" # from [c63bb866a148f074effe22c8ffe841f3fd0a626d] # to [8519266bfa44928b22734cbe8c390036c48a4bdf] # # patch "wiki/Win32DeviceFiles.mdwn" # from [c1353e12c84d989b3287afc18bb94294ab3a4159] # to [07b3e8ad71f4b7b47e20cf928e95346613f8d52a] # # patch "wiki/WorkspaceConflicts.mdwn" # from [d6e8b33e3bd331e1810e5a250ab9840de7a88f17] # to [eb3c241c080745930c41d3ed8937809668018c11] # # patch "wiki/ZeroConf.mdwn" # from [3042e2c268d5d8b67d55b7ba857e2cccdd742956] # to [fcaf391d10a4872549376bb0a519d50ea8a489b3] # # patch "wiki/elb.mdwn" # from [287a6f9eb937e60a8bc62a26e566592b60c53f6c] # to [968d409bec6596f7253702b87d445e576cb7b6c9] # # patch "wiki/gwk.mdwn" # from [2fe0f357a10dacf8fe81771e80cd70a88f1da04b] # to [7e2524db5b391277ff7d8fcb35d7c21662706fc3] # # patch "wiki/ikiwikimigration.mdwn" # from [fb956921940e6e928b33c62ac3a48fcb3a6a41cf] # to [e231239d22777ec4b1230971beec49a9e068cc38] # # patch "wiki/moin2mdwn.sed" # from [a743ebd62fb66765c90dcc3684302c979390052b] # to [b1552b53e20ff73abdb132a72cfac0be4184b96b] # # patch "wiki.mdwn" # from [3a38cfaeef8d1a3db85142c8256f0e7705575442] # to [f034719adafcec8b4a058925e8bb91f0de12e1ea] # ============================================================ --- wiki/AttrUseCases.mdwn 28ad729b1a091fd2bfcbf8b6aecf33bcbc19a010 +++ wiki/AttrUseCases.mdwn f2cc0b7ca01630f8a52a942f239e55a5f1588e17 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Attributes are really powerful, but it's not clear what parts of monotone should respond to them, what should be hookable, etc. To figure this out, here are some use cases for attributes: ============================================================ --- wiki/AutoInodeprints.mdwn 34e2067b3a72045144df0d3519db3b23ac0851cc +++ wiki/AutoInodeprints.mdwn ec0a46f34f1667d72990daf7c41c8b94cdd10e90 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Idea: on large trees, people uniformly will want to turn on inodeprints. It's a mildly reckless thing to do, but if everyone's going to make that trade-off, then making them all do it by hand it just obnoxious on our part. ============================================================ --- wiki/AutomateMagic.mdwn 9906e2fadd6fe925a4d0bf5ea413ea74ec491cc8 +++ wiki/AutomateMagic.mdwn 7a695ff7ff2d715c6213aba46ef22b3875c0f939 @@ -1,23 +1,17 @@ -[[tag migration-wip]] +[[tag migration-auto]] ### Show log entries for a given SELECTOR -{{{ -$ mtn automate select SELECTOR | mtn automate toposort address@hidden | xargs -L1 mtn log --last=1 -r -}}} + $ mtn automate select SELECTOR | mtn automate toposort address@hidden | xargs -L1 mtn log --last=1 -r ### Query the root or tail revision of BRANCH -{{{ -$ mtn automate heads BRANCH | mtn automate ancestors address@hidden | mtn automate toposort address@hidden | head -n1 -}}} + $ mtn automate heads BRANCH | mtn automate ancestors address@hidden | mtn automate toposort address@hidden | head -n1 -Optionally, add another {{{ | xargs -L1 mtn ls certs}}} to query for the certs of the revision. +Optionally, add another `| xargs -L1 mtn ls certs` to query for the certs of the revision. ### Find the base revision on another BRANCH This is useful if you want to generate a diff between the current head of a branch (taken from current workspace, see the second sub-command) and the branch your work is based on (specified in the first sub-command: nvm in the example). + $ mtn au common_ancestors `mtn au select h:net.venge.monotone` `mtn au select h:`|mtn au erase_ancestors address@hidden -{{{ -$ mtn au common_ancestors `mtn au select h:net.venge.monotone` `mtn au select h:`|mtn au erase_ancestors address@hidden -}}} ============================================================ --- wiki/AutomateVersions.mdwn 4b8e9e7df7890ae77715d6f6f359eb32289906c3 +++ wiki/AutomateVersions.mdwn 15822ad5346f8e37cb309b257d4c8440e93c30d4 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The rules to determine if the release version identifier X.Y is raised or not, are as follows: ============================================================ --- wiki/AutomateWishlist.mdwn 9e60a86c160b796410ad0dcbcb512bfe294bc090 +++ wiki/AutomateWishlist.mdwn f7b59a5dded365db4f96f16bf59c50640fd8fb10 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Missing (but useful) functions for the automate interface: @@ -50,59 +50,55 @@ The current form has the following descr The current form has the following description: -{{{ -The output consists of one or more packets for each command. A packet looks like: + The output consists of one or more packets for each command. A packet looks like: + + :::: + + is a decimal number specifying which command this output is from. It is 0 for the first command, and increases by one each time. + + is 0 for success, 1 for a syntax error, and 2 for any other error. + + is 'l' if this is the last piece of output for this command, and 'm' if there is more output to come. + + is the number of bytes in the output. + + is a piece of the output of the command. + + All but the last packet for a given command will have the field set to 'm'. -:::: - - is a decimal number specifying which command this output is from. It is 0 for the first command, and increases by one each time. - - is 0 for success, 1 for a syntax error, and 2 for any other error. - - is 'l' if this is the last piece of output for this command, and 'm' if there is more output to come. - - is the number of bytes in the output. - - is a piece of the output of the command. - -All but the last packet for a given command will have the field set to 'm'. -}}} - It is proposed to change it as so: -{{{ -The output consists of one or more packets for each command. A packet looks like: + The output consists of one or more packets for each command. A packet looks like: + + :::: + + is a decimal number specifying which command this output is from. It is 0 for the first command, and increases by one each time. + + is 0 for no-error, 1 for a syntax error, and 2 for any other error. no-error on the final 'l' packet (see below) for a command indicates success of the command; on earlier packets it means no error yet. Once an error has been detected and indicated with a packet with non-zero error value, no later packet should go back to 0. + + is an identifier for which output stream this packet represents, allowing multiple streams to be multiplexed over the channel. The following streams are presently defined; more streams may be added later. + + 'm' and 'l': the 'm' stream represents the normal stdout automate output of the command, formatted as described in the description for that command. The special 'l' value is described below. + + 'e': the 'e' stream represents any (unstructured) error message data. Internally, this maps to calls to the E() and N() print macros that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. + + 'w': the 'w' stream represents any (unstructured) warning message data. Internally, this maps to calls to the W() print macro that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. + + 'p': the 'e' stream represents any (unstructured) progress message data. Internally, this maps to calls to the P() print macro that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. + + As needed, some of these (e,w,p) messages may be replaced with structured and well-defined error information for more direct interpretation by a gui frontend, not localised, on a different stream. + + 'p': informative progress messages from the command during execution. + + 't': ticker updates, as may be used by the gui to update a progress bar. The ticker stream is formatted as a series of lines, one for each ticker update. Each line contains :[/]. The is the ticker name, is the value, the optional is the max value (which may be used for percentage in a progress bar). + + is the number of bytes in the output. + + is a piece of the output of the command. + + The last packet for a given command will have the field set to 'l'. This packet indicates termination of all streams for the command. Any content in this packet is considered to be part of the 'm' stream. The in this packet is likely to be zero if there has been an error message that has prevented or interrupted normal output. + + If a client implementation gets a record for a stream type it does not recognise, the record should be ignored. + -:::: - - is a decimal number specifying which command this output is from. It is 0 for the first command, and increases by one each time. - - is 0 for no-error, 1 for a syntax error, and 2 for any other error. no-error on the final 'l' packet (see below) for a command indicates success of the command; on earlier packets it means no error yet. Once an error has been detected and indicated with a packet with non-zero error value, no later packet should go back to 0. - - is an identifier for which output stream this packet represents, allowing multiple streams to be multiplexed over the channel. The following streams are presently defined; more streams may be added later. - - 'm' and 'l': the 'm' stream represents the normal stdout automate output of the command, formatted as described in the description for that command. The special 'l' value is described below. - - 'e': the 'e' stream represents any (unstructured) error message data. Internally, this maps to calls to the E() and N() print macros that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. - - 'w': the 'w' stream represents any (unstructured) warning message data. Internally, this maps to calls to the W() print macro that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. - - 'p': the 'e' stream represents any (unstructured) progress message data. Internally, this maps to calls to the P() print macro that would normally be written by the command to the program's stderr stream, if the automate sub-command had been called directly rather than via **stdio**. - -As needed, some of these (e,w,p) messages may be replaced with structured and well-defined error information for more direct interpretation by a gui frontend, not localised, on a different stream. - - 'p': informative progress messages from the command during execution. - - 't': ticker updates, as may be used by the gui to update a progress bar. The ticker stream is formatted as a series of lines, one for each ticker update. Each line contains :[/]. The is the ticker name, is the value, the optional is the max value (which may be used for percentage in a progress bar). - - is the number of bytes in the output. - - is a piece of the output of the command. - -The last packet for a given command will have the field set to 'l'. This packet indicates termination of all streams for the command. Any content in this packet is considered to be part of the 'm' stream. The in this packet is likely to be zero if there has been an error message that has prevented or interrupted normal output. - -If a client implementation gets a record for a stream type it does not recognise, the record should be ignored. - -}}} - The multiple stream encoding allows the output of errors and warnings to be associated with the command that generated them, allows the communication path to always stay in sync, and offers the opportunity to add other stream types for other useful purposes in the future as needs arise. ============================================================ --- wiki/BasicIoFormalization.mdwn 1a03eedc6b863debf07faf3103201420327e6d5c +++ wiki/BasicIoFormalization.mdwn 8a455aa003507af81235b7249aeaba12456e6a72 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] There's some debate on what the formal definition of basic_io should be, and in particular whether stanzas and lines should be first class items, or it should continue to treat all whitespace as identical, except with one special normalized form. @@ -21,9 +21,7 @@ Arguments to leave stanzas/lines as epip Arguments to leave stanzas/lines as epiphenomena: * meaningful whitespace is a generally bad idea. -{{{ - error cases with whitespace-sensitivity: pasting two stanzas together and forgetting to insert a newline. pasting two files together, inserting one extra newline, accidentally creating a "null stanza". wrapping. crlf conversion. -}}} + error cases with whitespace-sensitivity: pasting two stanzas together and forgetting to insert a newline. pasting two files together, inserting one extra newline, accidentally creating a "null stanza". wrapping. crlf conversion. also, whitespace mangling (though "" blocks can also be mangled). # Empirical questions ============================================================ --- wiki/BestPractices.mdwn 2e172c2d23098a8623f44ea8a1a67db550a695ab +++ wiki/BestPractices.mdwn 77bdf298eec6178b238eb1b928b1d46f521feeb7 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] There is more than one one way to get things done with monotone. Listed here is guidance in best practices in using monotone. Following these procedures will help you get the most out of monotone, and help avoid common pitfalls. ============================================================ --- wiki/BranchAnalogy.mdwn cc8a4bfd82b69aa080a21a7241208c6141307cda +++ wiki/BranchAnalogy.mdwn b1ca76dbc0b42416e650a28757cbb2f1e38daeba @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Monotone has a concept of branches that's internally quite different to some other VCS's. While it's very powerful and flexible, this has confused some users getting used to monotone's world. In particular: ============================================================ --- wiki/BranchNamingConventions.mdwn 195f41472ac53cb719e713fc95140febc5c1ccdd +++ wiki/BranchNamingConventions.mdwn 889e9077c9e48673ed6c07f05cff4f1d8951e6fd @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] There are a number of ways to create **globally unique** branch names. There's some debate about which one is best. @@ -49,7 +49,7 @@ Suggested by RichardLevitte. Doesn't loo *Note by RichardLevitte:* I don't agree that it requires a change to the selector syntax, as a domain name will always have at least one period. -*Note by ChadWalstrom:* I tested this on a Mac OS 10.4.x machine, creating a test branch named address@hidden:blah`. In the shell, the directory was correctly created as address@hidden:blah` upon checkout. It did not create a subdirectory as did the "/" character when chosen as a separator. However, when viewed in the {{{Finder}}} application, the directory was listed as address@hidden/blah`. The contradiction in representation of the folder name is confusing. The {{{Finder}}} does the correct thing when trying to descend into the directory, however. Practically speaking, this is cosmetic side-effect "bug". +*Note by ChadWalstrom:* I tested this on a Mac OS 10.4.x machine, creating a test branch named address@hidden:blah`. In the shell, the directory was correctly created as address@hidden:blah` upon checkout. It did not create a subdirectory as did the "/" character when chosen as a separator. However, when viewed in the `Finder` application, the directory was listed as address@hidden/blah`. The contradiction in representation of the folder name is confusing. The `Finder` does the correct thing when trying to descend into the directory, however. Practically speaking, this is cosmetic side-effect "bug". Supporters: RichardLevitte (obviously) @@ -106,16 +106,14 @@ Example: address@hidden, `monotone Example: address@hidden, address@hidden, address@hidden -{{{ - If we were to recommend something, I'd suggest a convention -[.sub[.]]@. E.g. address@hidden and address@hidden - Sorry, that's -[.[.]]@ -}}} + If we were to recommend something, I'd suggest a convention -[.sub[.]]@. E.g. address@hidden and address@hidden + Sorry, that's -[.[.]]@ Suggested by Nathan Myers. Simple, avoids fuss about selectors. Seems unlikely that people will actually register new emails for every branch, and it seems rude to have things that look like email addresses but aren't. / # Selector syntax -The basic problem is that selectors currently have both {{{:}}} and {{{/}}} as magic (meta) characters. These are the two characters that aren't already reserved by the shell (like {{{`'"!#$&*()<>?;"\|[]%}}}) or wanted for other things within selectors (like address@hidden which are all likely in email addresses and branch names). +The basic problem is that selectors currently have both `:` and `/` as magic (meta) characters. These are the two characters that aren't already reserved by the shell (like ```'"!#$&*()<>?;"\|[]%``) or wanted for other things within selectors (like address@hidden which are all likely in email addresses and branch names). This is less of an issue with monotone version 0.27 and later. Selectors can now be escaped with a `\` character, which will cause special characters to be ignored by the selector parser. The `:` is still treated as a special character is certain cases. @@ -123,8 +121,8 @@ Possible replacement characters include: * `~` -- only magical at the beginning of a shell token * , * possibly ^ -- it is magical in some contexts/some archaic shells, because it was the original pipe symbol. git uses it in a similar context. - * *{{{%}}} -- only magical (in Unix) at the beginning of a shell token, no longer common in email addresses.* -- Err, what about on windows, which does env-var substitution like %FOO%? - ''Good point. Well, {{{%%}}} would avoid that, or choosing a clause separator character not likely to appear in a variable name. (Windows passes the {{{%...%}}} construct unmodified if it doesn't match a defined variable).'' + * *`%` -- only magical (in Unix) at the beginning of a shell token, no longer common in email addresses.* -- Err, what about on windows, which does env-var substitution like %FOO%? + ''Good point. Well, `%%` would avoid that, or choosing a clause separator character not likely to appear in a variable name. (Windows passes the `%...%` construct unmodified if it doesn't match a defined variable).'' URL-like things require replacing /, which is used to separate multiple clauses in a selector. So we might end up with: * `b:venge.net/monotone~a:address@hidden ============================================================ --- wiki/BranchRenaming.mdwn b8db5634de32b04faa1fbc0a90b3a7d0d6675e0b +++ wiki/BranchRenaming.mdwn c8267fda96f52892e816c8968bbd85ea72af55da @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] *NB: patches to integrate this information into the manual proper would be gratefully accepted* @@ -7,74 +7,62 @@ The following commands can be used to re Branch renaming is not natively supported or encouraged in monotone, but if you feel you really need to do it, it is possible. Keep in mind, monotone is a distributed version control system. This means that even though you may rename a branch locally, unless every other database with that branch performs the same operation, the old branch will return the next time you do a `pull` or `sync` operation. The following commands can be used to rename a branch in your local copy. I would advise backing up the database before performing any of these operations. -{{{ -for REV in `mtn automate select b:OLDBRANCH`; do - mtn cert $REV branch NEWBRANCH -done -mtn db kill_branch_certs_locally OLDBRANCH -}}} + for REV in `mtn automate select b:OLDBRANCH`; do + mtn cert $REV branch NEWBRANCH + done + mtn db kill_branch_certs_locally OLDBRANCH If your branch names contain '/' characters, either escape the '/' characters or use the shell snippet below. -{{{ -for REV in `mtn db execute "SELECT id FROM revision_certs WHERE name = 'branch' AND value LIKE 'OLDBRANCH'" | grep ^[0123456789abcdef]*$`; do - mtn cert $REV branch NEWBRANCH -done -mtn db kill_branch_certs_locally OLDBRANCH -}}} + for REV in `mtn db execute "SELECT id FROM revision_certs WHERE name = 'branch' AND value LIKE 'OLDBRANCH'" | grep ^[0123456789abcdef]*$`; do + mtn cert $REV branch NEWBRANCH + done + mtn db kill_branch_certs_locally OLDBRANCH Basically this issues new branch certs for the branch you specifiy, and then the old branch certs are deleted. Be sure that the rename was successful (check with `mtn log`, `mtn list branches`, etc.) before issuing the `mtn db kill_branch_certs_locally` command. Note: You will have to enter your password once for every branch cert. To avoid this you can create a password hook in your `.monotonerc` file or use `yes PASSWORD | mtn cert...`, although that is not very secure (users can use ps aux or read your .bash_history to get your password). The ssh-agent integration available since mtn 0.34 is probably a solution to this, too. CraigLennox: These may fail with an "`argument list too long`" error if the branch contains a very large number (i.e. thousands) of revisions. You can get around that limitation by replacing instances of -{{{ -for REV in `mtn cmd args...`; do -}}} + for REV in `mtn cmd args...`; do with -{{{ -mtn cmd args... | while read REV; do -}}} + mtn cmd args... | while read REV; do # Branch Renaming Script Here is a script that can be used to rename branches, including names branch with `/` characters in them. Be sure to backup your database before using it. You must set the MTN_DB environment variable to the location of your database. -{{{ -#!/bin/bash + #!/bin/bash + + set -e + + if [ -z "$1" -o -z "$2" ]; then + echo "Usage: $0 old.branch.name new.branch.name" 1>&2 + exit 1 + fi + + if [ -z "$MTN_DB" ]; then + echo "MTN_DB not set" 1>&2 + exit 1 + fi + + # use sed here to escape '/' characters + OLD=$(echo $1 | sed -e '{s/\//\\\//g}') + NEW=$2 + + for REV in `mtn -d $MTN_DB automate select b:$OLD`; do + mtn -d $MTN_DB cert $REV branch $NEW + done + mtn -d $MTN_DB db kill_branch_certs_locally $1 -set -e -if [ -z "$1" -o -z "$2" ]; then - echo "Usage: $0 old.branch.name new.branch.name" 1>&2 - exit 1 -fi - -if [ -z "$MTN_DB" ]; then - echo "MTN_DB not set" 1>&2 - exit 1 -fi - -# use sed here to escape '/' characters -OLD=$(echo $1 | sed -e '{s/\//\\\//g}') -NEW=$2 - -for REV in `mtn -d $MTN_DB automate select b:$OLD`; do - mtn -d $MTN_DB cert $REV branch $NEW -done -mtn -d $MTN_DB db kill_branch_certs_locally $1 -}}} - - # Using A Ruby Shell To Manipulate Branches Using a ruby (or perl or python) shell can be a very convienient way to solve problems. -{{{ -% irb -irb> certs=`mtn automate select b:com.kiatoa.matt.rails`.split -=> ["0c597195698413293cc49691b0301b7f41af8be8", "17212d1b8058418432cf964754a2b08e16701e78", .... ] -irb> illegal="b715c|af49e0|7d7f" -irb> certs.each do |c| - if ! c.match(/^#{illegal}/) - system "mtn cert #{c} branch com.kiatoa.matt.rails2" + % irb + irb> certs=`mtn automate select b:com.kiatoa.matt.rails`.split + => ["0c597195698413293cc49691b0301b7f41af8be8", "17212d1b8058418432cf964754a2b08e16701e78", .... ] + irb> illegal="b715c|af49e0|7d7f" + irb> certs.each do |c| + if ! c.match(/^#{illegal}/) + system "mtn cert #{c} branch com.kiatoa.matt.rails2" + end end - end -}}} This allowed me to make a new branch with a head removed that I couldn't figure out how any other way to resolve. ============================================================ --- wiki/BranchStatuses.mdwn 3a294c70d9cc293ad71216673176a8b8e46bb793 +++ wiki/BranchStatuses.mdwn b88e30c47c2dc26d5d23b35ce1c19ec6dcb9f810 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Currently active development branches: ============================================================ --- wiki/BranchUI.mdwn 880da7619aff3fb0e3683611f80cb784502774c6 +++ wiki/BranchUI.mdwn 5c6fa2d2017409b16e73475da283bf176acba657 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Idea 1 ============================================================ --- wiki/BugSquashingParty.mdwn 9fc823e6825667b2d40881fe08c01d3330cd6b67 +++ wiki/BugSquashingParty.mdwn 5a747c42940290dc5c0db8e42be4cefe0ce5d23f @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] We're talking about having a Bug Squashing Party this weekend (November 26-27), with the goal of getting rosters merged. ============================================================ --- wiki/BuildBot.mdwn 100b7b92675080b560373def21c47a846a80039d +++ wiki/BuildBot.mdwn d4c2817a00e59d679731b11bcaaedc48c478f886 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The buildbot helps us make sure monotone continues to work on lots of platforms and configurations, and debug what's going wrong when things break. ============================================================ --- wiki/BuildingOnMac.mdwn cbec17ebfa915d864e1b1c79d830e760c4e795c1 +++ wiki/BuildingOnMac.mdwn 4f0de7c334ec8b597117edad21950d8e4835bd09 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Building Monotone on Mac OS/X @@ -11,40 +11,34 @@ Once you have installed the port tool, r (if */opt/local/bin* is not in your path, you can add it in a terminal shell by typing *PATH=/opt/local/bin:$PATH*) Once you have installed the port tool, run the following commands (enter your password when prompted): -{{{ -% sudo port install gettext + % sudo port install gettext + + % sudo port install autoconf + + % sudo port install automake -% sudo port install autoconf - -% sudo port install automake -}}} - # Getting the source Sometimes there is no pre-built binary of monotone on http://venge.net/monotone/downloads/ that is compatible with the version the development server is running. This means that if you want to synchronize and participate with the latest sources you will have to first build your own executable from a snapshot (*.tar.gz* file). It's not actually that hard, and the instructions in the *INSTALL* file which come in the archive will walk you through it. When you install boost it may not be put into your library path, but you can tell the configure script that generates the makefiles where it is: -{{{ -% ./configure CPPFLAGS="-I(BOOSTPATH)/boost_1_32_0" LDFLAGS="-L(BOOSTPATH)/boost_1_32_0/libs" -}}} + % ./configure CPPFLAGS="-I(BOOSTPATH)/boost_1_32_0" LDFLAGS="-L(BOOSTPATH)/boost_1_32_0/libs" If the executable you generate seems unreasonably large (over ~10 megabytes in size) then run *strip monotone* (or *strip -S* to keep basic symbols for debugging). Once you have a working monotone, then the following commands will let you grab the current development branch off the server: -{{{ -% monotone --db=mt.db db init + % monotone --db=mt.db db init + + % monotone --db=mt.db read <" for the addresses. @@ -86,9 +76,7 @@ For configure, I've used: To create a universal binary, first you'll need to create fat boost libraries. Build two separate sets of boost static libraries, one with *-arch ppc* and one with *-arch i386*. Then use *lipo -create* to produce a set of single .a files (use *file libboost_foo.a* to check that it worked). I then put header files in */usr/local/stow/boost-1.33.0-fat/include/boost* and the .a files in */usr/local/stow/boost-1.33.0-fat/lib*. For configure, I've used: -{{{ -./configure CFLAGS="-O2 -mdynamic-no-pic -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" CXXFLAGS="-O2 -mdynamic-no-pic -fno-threadsafe-statics -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" --enable-static-boost=/usr/local/stow/boost-1.33.0-fat CPPFLAGS="-pipe -I/usr/local/stow/boost-1.33.0-fat/include" LDFLAGS="-L/usr/local/stow/boost-1.33.0-fat/lib -dead_strip" --disable-dependency-tracking -}}} + ./configure CFLAGS="-O2 -mdynamic-no-pic -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" CXXFLAGS="-O2 -mdynamic-no-pic -fno-threadsafe-statics -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" --enable-static-boost=/usr/local/stow/boost-1.33.0-fat CPPFLAGS="-pipe -I/usr/local/stow/boost-1.33.0-fat/include" LDFLAGS="-L/usr/local/stow/boost-1.33.0-fat/lib -dead_strip" --disable-dependency-tracking You should then be able to just *make*, though note that distcc doesn't seem to work with multiple *-arch* flags, since it uses the *-E* gcc option. The final output binary will be massive, so *strip -S* is recommended for distribution. An alternative approach to making a universal binary is to just build two separate monotone binaries, then *lipo -create* to stick them together. ============================================================ --- wiki/BuildingOnSolaris.mdwn c8bfbc121048baa94dc5d7a6f808fe9a30d533f3 +++ wiki/BuildingOnSolaris.mdwn ec5f4fc37090aee0c79bb06e0f74d6902c138d4b @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # GCC build The last experiences I had with that are 0.20-era and thus outdated. gcc, as delivered by sun is also a rapidly moving target with all kinds of bugs esp. in its copy of system headers and c++ headers. @@ -16,12 +16,12 @@ For older versions of Boost, you need [h For older versions of Boost, you need [http://blogs.sun.com/roller/page/sga some patches] to the boost source itself, as its knowledge of sun studio's features is rather limited. You'll find the patches, as well as build instructions on the right pane on the site. [http://blogs.sun.com/roller/resources/sga/boost_1_32_0.patch Base patch] [http://blogs.sun.com/sga/resource/operations_posix_windows.cpp Additional patch to avoid segfaults in operations on large trees] ## Compiling -You'll need {{{CXXFLAGS=-library=stlport4 -features=tmplife -features=tmplrefstatic}}}. Adding {{{-Qoption ccfe -complextmplexp}}} might help in case of problems, but the documentation warns that it might produce wrong name mangling (I use it for the packages without any issues, though --PatrickGeorgi). +You'll need `CXXFLAGS=-library=stlport4 -features=tmplife -features=tmplrefstatic`. Adding `-Qoption ccfe -complextmplexp` might help in case of problems, but the documentation warns that it might produce wrong name mangling (I use it for the packages without any issues, though --PatrickGeorgi). ### Locales You might run into issues with libiconv if there's more than just the SUN version installed in a way that the compiler will pick it up. Unfortunately, the gettext macros for autotools get a bit confused by such a scenario and might try to link against the SUN libraries but using the GNU headers on build time, which fails. -A solution is to configure with {{{--with-iconv-prefix=/usr --with-libintl-prefix=/usr}}} __and__ to remove the gnu iconv headers from any kind of compiler search path. +A solution is to configure with `--with-iconv-prefix=/usr --with-libintl-prefix=/usr` __and__ to remove the gnu iconv headers from any kind of compiler search path. If you don't have GNU iconv installed, you won't get locales support at all (but at least, it builds). The reason for that lies in the gettext macros that we inherited from gnu gettext, which only look for the GNU flavor (wasn't autoconf made for portability and finding out such differences?) ============================================================ --- wiki/BuildingOnWindows/VC8.mdwn bdd4f56d523bc78d3e5a377140ab3aaf7d629f6a +++ wiki/BuildingOnWindows/VC8.mdwn 1bf81a149149a34c67a4122be1693b5fdece1b8d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Installing the toolchain This section is preliminary setup--once this has been completed once, you can ============================================================ --- wiki/BuildingOnWindows/VisualC8.mdwn bdbfab37f2165a12c375a5aa4dce84077e6a43cf +++ wiki/BuildingOnWindows/VisualC8.mdwn 76798f508e9c80417ba72fb7bfd73403b94a7634 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Installing the toolchain ============================================================ --- wiki/BuildingViaPkgsrc.mdwn d2a5a7207282a2b62df155cfe6916250faa52b47 +++ wiki/BuildingViaPkgsrc.mdwn 907e3c4997271b97bd76e537f5047576e9e91536 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] You can build monotone from source yourself on a number of platforms, and several pages in the wiki describe the process in some detail for various platforms. Monotone itself is pretty easy to compile, most of the detail on these pages deals with getting the various dependencies (like boost) installed first. You might like to try using pkgsrc to take care of all of these steps for you. @@ -25,10 +25,8 @@ Once you have pkgsrc set up, installing # Building monotone Once you have pkgsrc set up, installing [http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/monotone/README.html the monotone pkg] and its dependencies is easy: -{{{ - # cd /usr/pkgsrc/devel/monotone - # bmake install -}}} + # cd /usr/pkgsrc/devel/monotone + # bmake install There are also packages for many other InterfacesFrontendsAndTools that work with monotone. ============================================================ --- wiki/CarrotAndStick.mdwn dd68135ee164e40b236eabafd71a9d4b9702d511 +++ wiki/CarrotAndStick.mdwn c46bbeb49ce1014c7bf4b4711dae38321d0f8e92 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] In order to form a more perfect UI... ============================================================ --- wiki/CaseInsensitiveFilesystems.mdwn 399c68b79dd983fa10befc1f14d63b6e9cd67696 +++ wiki/CaseInsensitiveFilesystems.mdwn 775d3ce9d7dbbace6e09a504dbf733803bef2fbd @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Discussion: irc logger missed it, but, in #monotone around 2005-12-12T00:00:00 UTC. ============================================================ --- wiki/CertCleanup.mdwn c719e5fe06aab7d1b9c58e1aee6528573f6b69c1 +++ wiki/CertCleanup.mdwn 860f798a0396949199f247d60702336f30b88e5f @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] While we're doing VersionedPolicy, we probably want to take the opportunity to clean up some stuff about how we do certs. ============================================================ --- wiki/ChadWalstrom.mdwn d5766ac6ec33842ae18443b6cc37ae5dae8b093a +++ wiki/ChadWalstrom.mdwn 9cb1551ef351465a9a0b037580a974675ac40191 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] GNU Arch refugee since monotone 0.18. * [[MailTo(chewie AT wookimus DOT net)]] ============================================================ --- wiki/ChangeLog.mdwn a41c6e2186c7baf99020cb9ec77d639d1f573b1c +++ wiki/ChangeLog.mdwn b851c0c5dacdb0ba1cc9c4afe3c3a33fba319128 @@ -1,155 +1,153 @@ -[[tag migration-wip]] +[[tag migration-auto]] -This is a first little piece of emacs-code, to achieve the task of writing log messages to {{{_MTN/log}}} instead of {{{ChangeLog}}} if appropriate. (Note that [http://download.gna.org/dvc/ DVC] already includes a similar feature, bound to C-x V a by default.) +This is a first little piece of emacs-code, to achieve the task of writing log messages to `_MTN/log` instead of `ChangeLog` if appropriate. (Note that [http://download.gna.org/dvc/ DVC] already includes a similar feature, bound to C-x V a by default.) -Look at the source for a way to use it. From now on use {{{mtn-add-change-log-entry}}} instead of {{{add-change-log-entry}}}. {{{mtn-add-change-log-entry}}} will try do the right thing. +Look at the source for a way to use it. From now on use `mtn-add-change-log-entry` instead of `add-change-log-entry`. `mtn-add-change-log-entry` will try do the right thing. -If a directory named {{{_MTN}}} exists in the buffers {{{default-directory}}} or in any parent directory, use {{{_MTN/log}}}, {{{../_MTN/log}}} or whatsoever. {{{./ChangeLog}}} (or better {{{change-log-default-name}}} as from customize) otherwise. All your customisations ({{{M-x customize-group RET change-log RET}}}) work as expected. +If a directory named `_MTN` exists in the buffers `default-directory` or in any parent directory, use `_MTN/log`, `../_MTN/log` or whatsoever. `./ChangeLog` (or better `change-log-default-name` as from customize) otherwise. All your customisations (`M-x customize-group RET change-log RET`) work as expected. -I have a symbolic link named {{{current}}} in my home directory, that always points the folder of the project I'm currently working on. If I {{{mtn-add-change-log-entry}}} on a file in there, these functions still search up the real directory tree. +I have a symbolic link named `current` in my home directory, that always points the folder of the project I'm currently working on. If I `mtn-add-change-log-entry` on a file in there, these functions still search up the real directory tree. -So if {{{/home/sebastian/current}}} points to {{{/home/sebastian/develop/gtkmm/application/src}}}, and there are {{{/home/sebastian/develop/gtkmm/_MTN}}} AND {{{/home/sebastian/_MTN}}}, {{{mtn-add-changelog-entry}}} will choose {{{/home/sebastian/develop/gtkmm/_MTN/log}}}. +So if `/home/sebastian/current` points to `/home/sebastian/develop/gtkmm/application/src`, and there are `/home/sebastian/develop/gtkmm/_MTN` AND `/home/sebastian/_MTN`, `mtn-add-changelog-entry` will choose `/home/sebastian/develop/gtkmm/_MTN/log`. -Since {{{mtn-add-change-log-entry}}} calls {{{add-change-log-entry}}} interactively, you still can choose to write to use an other file. +Since `mtn-add-change-log-entry` calls `add-change-log-entry` interactively, you still can choose to write to use an other file. -{{{ -;; File: sr-monotone.el -;; $Revision: 1.2 $ -;; Date: 2006-12-04 -;; Author: Sebastian Rose -;; License: GPL -;; -;; Copyright (c) 2006 Sebastian Rose -;; -;; -;; Provides to funktions: -;; * mtn-get-parent-directory (child) -;; returns the parent directory or nil, if there is no parent. -;; I wrote it, since I could not find a function like this. -;; * mtn-add-change-log-entry () -;; looks for _MTN directory and changes the behaviour of -;; add-change-log-entry to use /PATH/TO/_MTN as directory -;; and 'log' as the default filename for the logfile. -;; -;; -;; -;; Usage: -;; -;; THE ONE WAY -;; In your .emacs put this line: -;; (require 'sr-monotone) -;; ... and place this file somewhere in your load-path. -;; -;; -;; THE OTHER WAY -;; Copy the two functions here and paste them in your .emacs. -;; -;; -;; -;; Bind any key you like to mtn-add-change-log-entry. -;; (global-set-key [(f8)] 'mtn-add-change-log-entry) -;; -;; From now on only use mtn-add-change-log-entry. It detects automagically the -;; right way to call add-change-log-entry. - -(provide 'sr-monotone) - - -(defun mtn-get-parent-directory (child) - "Retruns the parent directory or nil, if there is no parent. -Parent has always a trailing slash, or what ever is your systems -file separtor. -Improvements and suggestions to address@hidden" - (if (file-regular-p child) - (file-name-as-directory (file-name-directory child)) - ; this is else: - (let ((child (file-name-as-directory child))) - (let ((dir (file-name-as-directory (expand-file-name child))) - (parent (file-truename - (file-name-as-directory (expand-file-name (concat child "..")))))) - (if (string= dir parent) - nil - parent))))) - - - -(defun mtn-add-change-log-entry() - "Searches in buffers default-directory and above for a directory -named '_MTN'. If it exists, monotone-add-change-log-entry calls -add-change-log-entry interactively with apropriate arguments. -Otherwise interactively calls add-change-log-entry the normal way. -So one can just bind this function to the keys, that call -add-change-log-entry now, and it will work just fine. - -Improvements and suggestions to address@hidden" -(interactive) - (let ((filename buffer-file-name) - (is-mtn-dir nil) - (original-default-directory default-directory) - (original-change-log-filename nil)) - (if (boundp 'change-log-default-name) - (setq original-change-log-filename change-log-default-name)) - (unwind-protect - (progn - (if filename - (progn - (catch 'done - (while (setq filename (mtn-get-parent-directory filename)) - (if (file-directory-p (concat filename "_MTN")) - (progn - (setq change-log-default-name "log") - (setq is-mtn-dir (concat filename "_MTN")) - (throw 'done 'is-mtn-dir))))) - (if is-mtn-dir - (let ((default-directory is-mtn-dir)) + ;; File: sr-monotone.el + ;; $Revision: 1.2 $ + ;; Date: 2006-12-04 + ;; Author: Sebastian Rose + ;; License: GPL + ;; + ;; Copyright (c) 2006 Sebastian Rose + ;; + ;; + ;; Provides to funktions: + ;; * mtn-get-parent-directory (child) + ;; returns the parent directory or nil, if there is no parent. + ;; I wrote it, since I could not find a function like this. + ;; * mtn-add-change-log-entry () + ;; looks for _MTN directory and changes the behaviour of + ;; add-change-log-entry to use /PATH/TO/_MTN as directory + ;; and 'log' as the default filename for the logfile. + ;; + ;; + ;; + ;; Usage: + ;; + ;; THE ONE WAY + ;; In your .emacs put this line: + ;; (require 'sr-monotone) + ;; ... and place this file somewhere in your load-path. + ;; + ;; + ;; THE OTHER WAY + ;; Copy the two functions here and paste them in your .emacs. + ;; + ;; + ;; + ;; Bind any key you like to mtn-add-change-log-entry. + ;; (global-set-key [(f8)] 'mtn-add-change-log-entry) + ;; + ;; From now on only use mtn-add-change-log-entry. It detects automagically the + ;; right way to call add-change-log-entry. + + (provide 'sr-monotone) + + + (defun mtn-get-parent-directory (child) + "Retruns the parent directory or nil, if there is no parent. + Parent has always a trailing slash, or what ever is your systems + file separtor. + Improvements and suggestions to address@hidden" + (if (file-regular-p child) + (file-name-as-directory (file-name-directory child)) + ; this is else: + (let ((child (file-name-as-directory child))) + (let ((dir (file-name-as-directory (expand-file-name child))) + (parent (file-truename + (file-name-as-directory (expand-file-name (concat child "..")))))) + (if (string= dir parent) + nil + parent))))) + + + + (defun mtn-add-change-log-entry() + "Searches in buffers default-directory and above for a directory + named '_MTN'. If it exists, monotone-add-change-log-entry calls + add-change-log-entry interactively with apropriate arguments. + Otherwise interactively calls add-change-log-entry the normal way. + So one can just bind this function to the keys, that call + add-change-log-entry now, and it will work just fine. + + Improvements and suggestions to address@hidden" + (interactive) + (let ((filename buffer-file-name) + (is-mtn-dir nil) + (original-default-directory default-directory) + (original-change-log-filename nil)) + (if (boundp 'change-log-default-name) + (setq original-change-log-filename change-log-default-name)) + (unwind-protect + (progn + (if filename + (progn + (catch 'done + (while (setq filename (mtn-get-parent-directory filename)) + (if (file-directory-p (concat filename "_MTN")) + (progn + (setq change-log-default-name "log") + (setq is-mtn-dir (concat filename "_MTN")) + (throw 'done 'is-mtn-dir))))) + (if is-mtn-dir + (let ((default-directory is-mtn-dir)) + (call-interactively 'add-change-log-entry)) (call-interactively 'add-change-log-entry)) + ))) + (setq default-directory original-default-directory) + (setq change-log-default-name original-change-log-filename) + ))) + + + + ;; 2006-16-12 + ;; This function is the one you need, to make add-change-log-entry + ;; print the path of the file you're writing the change log entry for + ;; relative to the root of your project directory. + ;; If change-log-default-name is "log", this function assumes the + ;; file is part of a monotone project and return the files path + ;; relative to "/_MTN/..", just like monotone commands would do. + ;; Otherwise returns the path of the file relative to the directory, + ;; where the log file lives in. + ;; + ;; No leading slash prepended. + ;; + ;; To use this function type + ;; M-x customize-variable RET add-log-file-name-function RET + ;; and make it point to mtn-add-log-file-name. + ;; Unfortunately this function relies on log-file, which is an undocumented + ;; variable in add-log.el, actually a local variabel in function + ;; add-log-file-name (buffer-file log-file). + ;; But I couldn't find an other way, to get the logfile, the user has + ;; choosen at this point. + ;; + (defun mtn-add-log-file-name(original-name) + "Return the filename printed in _MTN/log (or ChangeLog) relative to + the projects root. That is the driectory the file ChangeLog lives in, + if not a monotone project, _MTN/../ otherwise. + + Improvements and suggestions to address@hidden" + + (let ((directory (mtn-get-parent-directory log-file)) + (file (file-truename original-name))) + + (if (string= change-log-default-name "log") + ;; monotone + (let ((directory (mtn-get-parent-directory directory))) + (file-relative-name file directory)) + ;; else no monotone: + (file-relative-name file directory)))) + - (call-interactively 'add-change-log-entry)) - ))) - (setq default-directory original-default-directory) - (setq change-log-default-name original-change-log-filename) - ))) - - - -;; 2006-16-12 -;; This function is the one you need, to make add-change-log-entry -;; print the path of the file you're writing the change log entry for -;; relative to the root of your project directory. -;; If change-log-default-name is "log", this function assumes the -;; file is part of a monotone project and return the files path -;; relative to "/_MTN/..", just like monotone commands would do. -;; Otherwise returns the path of the file relative to the directory, -;; where the log file lives in. -;; -;; No leading slash prepended. -;; -;; To use this function type -;; M-x customize-variable RET add-log-file-name-function RET -;; and make it point to mtn-add-log-file-name. -;; Unfortunately this function relies on log-file, which is an undocumented -;; variable in add-log.el, actually a local variabel in function -;; add-log-file-name (buffer-file log-file). -;; But I couldn't find an other way, to get the logfile, the user has -;; choosen at this point. -;; -(defun mtn-add-log-file-name(original-name) - "Return the filename printed in _MTN/log (or ChangeLog) relative to -the projects root. That is the driectory the file ChangeLog lives in, -if not a monotone project, _MTN/../ otherwise. - -Improvements and suggestions to address@hidden" - - (let ((directory (mtn-get-parent-directory log-file)) - (file (file-truename original-name))) - - (if (string= change-log-default-name "log") - ;; monotone - (let ((directory (mtn-get-parent-directory directory))) - (file-relative-name file directory)) - ;; else no monotone: - (file-relative-name file directory)))) - -}}} ============================================================ --- wiki/CherryPicking.mdwn 02db5fd6b04b151328347871f745a57dd7259713 +++ wiki/CherryPicking.mdwn 35c13a05b12ed721682eb28d86312db13f649efc @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] "Cherry picking" is an extension to merge that allows changes between arbitrary versions to be merged into the current version. ============================================================ --- wiki/ChristofPetig.mdwn 68bfdf45f079aca4a14eff4e883a9448b770b367 +++ wiki/ChristofPetig.mdwn c9bc104754ff7756e98d2ce4691224d2201b6cf0 @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] E-Mail: address@hidden ============================================================ --- wiki/CraigLennox.mdwn 0d58a96602111ae00ab7dae7fa6c4b1c68ca8ffd +++ wiki/CraigLennox.mdwn f06ae2e40410ef0d65816d5f76e5861db5fea2f4 @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] I've been a happy user of Monotone since 0.15. ============================================================ --- wiki/CreatingBranches.mdwn b1f7c9b4e653c3dfda3fbf2e83ac428f8792f0f5 +++ wiki/CreatingBranches.mdwn f16ff2700744b1edcf973cdb35b55ecd195881f2 @@ -1,15 +1,13 @@ -[[tag migration-wip]] +[[tag migration-auto]] If you want to create a new branch, the most intuitive way (that I've found) is to commit your changes with --branch= . -Alternatively, you may want to create a branch on an existing codebase before you have any changes to commit. To create a branch from the current workspace's revision, use the {{{mtn cert}}} e.g. {{{ +Alternatively, you may want to create a branch on an existing codebase before you have any changes to commit. To create a branch from the current workspace's revision, use the `mtn cert` e.g. {{{ mtn cert h: branch com.yoyodine.bunchy.testing }}} You can then update to the branch: -{{{ -mtn update --branch com.yoyodine.bunchy.testing -}}} + mtn update --branch com.yoyodine.bunchy.testing Advantages of this approach are that multiple developers can update and begin working and committing to that branch straight away without having to coordinate their first commit between them. Also, I'm very forgetful, and I find that I often accidentally commit to the head - it's easy to forget that you intended to start a new branch, so making this the first step in your workflow prevents this happening. ============================================================ --- wiki/CvsImport.mdwn 4ce058f21673400073d7007b050cff953342aa90 +++ wiki/CvsImport.mdwn 36b58350740c8982cb1b07a2267b5eefd0688a11 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Importing CVS repositories with Graph Based Algorithms @@ -79,5 +79,5 @@ Tested with: 040f83b3bcd4c04adc7e3947d06 Tested with: 040f83b3bcd4c04adc7e3947d06a9ccffc223ad5 2008-05-01T14:00:49 + * netbsd/othersrc: creating monotone revs: `../nvm.cbr/rcs_import.cc:5,018: invariant 'I(parent_blobs.size() == 1)' violated` + * openssl/openssl: cycle splitting stage: `../nvm.cbr/rcs_import.cc:3,598: invariant 'I(false)' violated` - * netbsd/othersrc: creating monotone revs: {{{../nvm.cbr/rcs_import.cc:5,018: invariant 'I(parent_blobs.size() == 1)' violated}}} - * openssl/openssl: cycle splitting stage: {{{../nvm.cbr/rcs_import.cc:3,598: invariant 'I(false)' violated}}} ============================================================ --- wiki/CvsSync.mdwn 92804911fad04a6f54fa3c3eafd8e46ecdd729a2 +++ wiki/CvsSync.mdwn aeae341030e253f2ca05f240b0b1f1a891918e2c @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] see CvsSyncHints and CvsSyn3 ============================================================ --- wiki/CvsSync3.mdwn 73333f0252e0c030af2a6d7ac44108c199989e3b +++ wiki/CvsSync3.mdwn 35b1730ef42e0671cd21ee6832bc329f9de35226 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # CvsSync rewrite #3 ============================================================ --- wiki/DagBasedRefinement.mdwn 12853aa0f5827d4b57db17d7c60130296f808027 +++ wiki/DagBasedRefinement.mdwn 8c7c7619b63fa5f0d05b746ad1a22a1e40fcf727 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Originally posted at http://lists.gnu.org/archive/html/monotone-devel/2006-09/msg00124.html . There's also a little bit of discussion at http://colabti.de/irclogger/irclogger_log/monotone?date=2006-09-08,Fri&sel=234#l464 . ============================================================ --- wiki/DaggyFixes.mdwn 1f2136f48e8ec7e2a152b4c037ada0f029670a83 +++ wiki/DaggyFixes.mdwn 4f96fcfd13ff0cb7e2c3cdd7ae058dab467e8672 @@ -191,9 +191,9 @@ Even better, because `F2` and `R2` have inherited the bug, and is therefore also going to need the fix. Even better, because `F2` and `R2` have a common ancestor `B` (which -introduced the bug), and `F2` contains ''only'' the fix for the bug, +introduced the bug), and `F2` contains *only* the fix for the bug, approving `F2` to that branch (and merging, as before) does -''exactly'' the right thing, producing a fixed revision `RF` on the +*exactly* the right thing, producing a fixed revision `RF` on the branch: A ============================================================ --- wiki/DatabaseLocking.mdwn 4de6bde9707ce9f70e2961118222959bb01c1af4 +++ wiki/DatabaseLocking.mdwn c2e334f09b21115db6cf3a0ce6262b5f84576dbe @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] *(source discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-12-08,Thu&sel=90#l151)* ============================================================ --- wiki/DeltaStorageStrategies/ShootOut.mdwn 6f52fe1f30481dce1482e63225e8ea2066b9cee5 +++ wiki/DeltaStorageStrategies/ShootOut.mdwn c5ae1c718327b7cceaf63112bd5f5fac5a3219d9 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] || *When the going gets tough, the tough get empirical.* || ============================================================ --- wiki/DeltaStorageStrategies.mdwn d798bb1c080834f4d9f15a5f5a30d4f9f077769d +++ wiki/DeltaStorageStrategies.mdwn 9a0188f708cf39a7c55e8f816a60db26d2960744 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Here are some of the known ways one *could* potentially do delta-compression on large version corpora. @@ -54,12 +54,10 @@ Storing full files when size(del(base,ne For the initial net.venge.monotone* database, of size 90,074,112: (all sizes are vacuumed) Storing full files when size(del(base,new)) > N*size(base): -{{{ -N=0.10: 152,059,904 -N=0.15: 171,443,200 -N=0.20: 183,305,216 -N=0.30: 213,744,640 -}}} + N=0.10: 152,059,904 + N=0.15: 171,443,200 + N=0.20: 183,305,216 + N=0.30: 213,744,640 So this is fairly consistent with drh's experiments, with a ~1.5x-2x size increase. Cold-cache checkout times for head are slightly shorter with the normal reverse-chained-delta database (though may be experimental error). ## Revlog variations ============================================================ --- wiki/DerekScherger.mdwn 7c23559593fcc0b960f0a6af6ce6a4f0e7371b5a +++ wiki/DerekScherger.mdwn 8231dd334d3a3c56a9e5e635bd7c23f0cc0f13e0 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/DevGroup.mdwn 0aa37b3c943fd9489bae7d72a5e7b5364076f178 +++ wiki/DevGroup.mdwn 44cbac762fe960037d5a0ab4d10039b3ae35f8c6 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #acl DevGroup:admin,read,write All:read ============================================================ --- wiki/EmileSnyder.mdwn aa9316ddc5d5b96ce1bb42a4b1fa97da566938d5 +++ wiki/EmileSnyder.mdwn cea9a1ea3cce40b6b21f928c6bf52a107fbfd52b @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/EssentialMonotone.mdwn faf145c09aed47b366d630a5c00f4e3b016322fd +++ wiki/EssentialMonotone.mdwn e47245d221a6d8afc661e733e940e2fa2655604e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] What is the bare minimum command set needed to use monotone? ============================================================ --- wiki/Feature/AccessControl.mdwn 602447a5122d82a14117f80dfdf3a1e89f5551cb +++ wiki/Feature/AccessControl.mdwn 23630975ba047e00ca4d718ae191f0306119d5f1 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/AtomicCommit.mdwn 25ad516ced4862d86105b75d4ec61c49effc9a19 +++ wiki/Feature/AtomicCommit.mdwn d6f957b72af66fd140e05cf6d634546b81986750 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -16,9 +16,7 @@ Commits are atomic both in the VCS sense # Example Usage -{{{ - $ mtn commit -}}} + $ mtn commit # Further Reference ============================================================ --- wiki/Feature/BuildIntegration.mdwn be9278519c0ab85a38f369d6870d40fa34b967f6 +++ wiki/Feature/BuildIntegration.mdwn 36bbc941f66e054108f83bc1678a834e18ee146e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/CVSExport.mdwn df4ff494269e75202d77a795b5e2e68342bafc6a +++ wiki/Feature/CVSExport.mdwn 0d107390d040be02a22f3407ab7a427a31dc05c5 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/CVSImport.mdwn 5c6300c9fe93bb2590b185e4444478c09a1c7a80 +++ wiki/Feature/CVSImport.mdwn e4c82c358adee251cc2925d6a6443a6ec7bc028a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -15,9 +15,7 @@ To import a full CVS history, you need a # Example Usage To import a full CVS history, you need a copy of the cvsroot `,v` files: -{{{ - $ mtn -d /some/path/project.mtn cvs_import -b org.project $CVSROOT/dir -}}} + $ mtn -d /some/path/project.mtn cvs_import -b org.project $CVSROOT/dir This will create a branch called `org.project` with contents and history that you would get from `cvs co dir`. Any CVS branches in that history will be created with names like `org.project.cvs-branch-name`. ============================================================ --- wiki/Feature/CommitMail.mdwn 67ec4dcec228783fc0eb8b18a14be89f7c3c1c38 +++ wiki/Feature/CommitMail.mdwn 895c8d7544d1a271a13a2d1a160e69b350414cb3 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/CompactRepository.mdwn 98b623ce12da9e23ac4543f5baaedf73a76706e9 +++ wiki/Feature/CompactRepository.mdwn 43e51184ebc4660a7a6e12a2191a3c8de23931b8 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/EmbeddedIDs.mdwn b1dd19db90df9c62f18d6a979fd84e4a82f825f0 +++ wiki/Feature/EmbeddedIDs.mdwn 2fb64ae787892c98f500e1bc0dbf9e035a0ec194 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/Fast.mdwn 30efd1cd6f42c4b0580efc513d21463a04b0ae79 +++ wiki/Feature/Fast.mdwn e75bb1e1aec583f45fa9bb0a086ad82a12bde0b8 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/LightweightBranches.mdwn d8ec536deeb0f29e7f83d8ce4791fe28ca0f0b78 +++ wiki/Feature/LightweightBranches.mdwn 04a8621513880ef88129ded11167a2040ee781ed @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -17,10 +17,8 @@ To commit some changes in a workspace to # Example Usage To commit some changes in a workspace to a new branch: -{{{ - - $ mtn commit -b com.example.new-branch-name -}}} + + $ mtn commit -b com.example.new-branch-name # Further Reference ============================================================ --- wiki/Feature/LogReview.mdwn 47bdd8f9d66eafa14c1e8bdb822d7e3ac89369f9 +++ wiki/Feature/LogReview.mdwn a5c264c46039a06658e179a60ae5ed112fb519d2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/LogTemplates.mdwn ff0d39741e3af68270d6f66c6dbe0020eb6d7ffc +++ wiki/Feature/LogTemplates.mdwn f1ceb981deab3f53450d28a5fb7f3d4750c7de03 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/MIMEtypes.mdwn 5eac1573212dcdd39fa83463c58ef13b3a347566 +++ wiki/Feature/MIMEtypes.mdwn c9acd4b2de1d8031a47d51e8b838925f3025922c @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -12,10 +12,8 @@ There is no explicit support for MIME-ty # Example Usage -{{{ - $ mtn attr set *.html MIMEType text/html - $ mtn commit -}}} + $ mtn attr set *.html MIMEType text/html + $ mtn commit # Further Reference ============================================================ --- wiki/Feature/Merging.mdwn 16325f0f42a0b0e20fe053f9dfefc3cdb84ae8e8 +++ wiki/Feature/Merging.mdwn ef54056003a95437815e95e03c990e4c54772eb2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -19,16 +19,14 @@ A very common developer loop: # Example Usage A very common developer loop: -{{{ - - $ mtn commit - $ mtn pull - - $ mtn merge - $ mtn sync - - $ mtn update -}}} + + $ mtn commit + $ mtn pull + + $ mtn merge + $ mtn sync + + $ mtn update # Further Reference ============================================================ --- wiki/Feature/Mirroring.mdwn e9fec1d6599111682bca5a82346d9957c16719fd +++ wiki/Feature/Mirroring.mdwn 80e9511b3332f2fc66cab018bf6a740c96380ecf @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -16,11 +16,9 @@ If independent monotone servers are runn # Example Usage If independent monotone servers are running at `server1` and `server2`, a developer with write privileges to both servers can replicate content between them simply by syncing with each server: -{{{ - $ mtn sync server1 - $ mtn sync server2 - $ mtn sync server1 -}}} + $ mtn sync server1 + $ mtn sync server2 + $ mtn sync server1 If either of these servers had new revisions, those revisions will be transferred to the developer's database, and then to the other server if it was not yet aware of them. In order to make them identical mirrors, use the branch pattern `'*'` for all syncs, otherwise more selective patterns can be used for partial replicas. ============================================================ --- wiki/Feature/NetworkSecurity.mdwn d2d1cb04c0b62e3594ee5b8173c341f49f05eba9 +++ wiki/Feature/NetworkSecurity.mdwn ac5939ceb9a3919fad1e7e33ce60c8dbe6c2b17b @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/Obliterate.mdwn 94388e7338b7d632fa402748e96105bbeaff001d +++ wiki/Feature/Obliterate.mdwn 15c2166ae0fbb021452c4f9c93f847be891792df @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -19,17 +19,13 @@ Revisions can be removed from a local da # Example Usage Revisions can be removed from a local database, if they have no descendants: -{{{ - $ mtn -d database.mtn db kill_rev_locally -}}} + $ mtn -d database.mtn db kill_rev_locally If there are descendants, additional changes have been based on the bad revisions and they must also be removed. If they're unrelated and still wanted, they must be reapplied to an ancestor of the old revision (most likely using `pluck`). Removing the revisions does not remove the file content. This can be removed with a local sync to a new database, which won't transfer the now-unreferenced file content -{{{ - $ mtn -d new.mtn db init - $ mtn -d old.mtn sync file://new.mtn '*' -}}} + $ mtn -d new.mtn db init + $ mtn -d old.mtn sync file://new.mtn '*' These steps will need to be taken on all affected databases. If this number is known to be large, the branch epoch feature can be used to render clean and dirty databases incompatible and prevent accidental re-pollution. ============================================================ --- wiki/Feature/Offline.mdwn cf75aa0a5f61a7f29a62f527f5a0edf0b5f65093 +++ wiki/Feature/Offline.mdwn 56f350439566a7611c36a24785346487d9118679 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -18,13 +18,11 @@ All of the following (and many other thi # Example Usage All of the following (and many other things besides) work entirely offline: -{{{ - $ mtn log --last=3 file.c - - $ mtn diff file.c - $ mtn diff -r t:some-release-tag file.c - $ mtn commit -}}} + $ mtn log --last=3 file.c + + $ mtn diff file.c + $ mtn diff -r t:some-release-tag file.c + $ mtn commit # Further Reference ============================================================ --- wiki/Feature/Portable.mdwn 8e869a5838741208c3ab03e3eacdc503f3113ae6 +++ wiki/Feature/Portable.mdwn cc39429eec037bca0c1c507ce2565d07a3c018a5 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/Rename.mdwn 6c7fd056de73915f8df7438bfcdab69cf6ceee06 +++ wiki/Feature/Rename.mdwn ffeb9e545140e5741a9a9643b393fac617ab4397 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -13,11 +13,9 @@ To rename a file: # Example Usage To rename a file: -{{{ - $ mtn rename -e foo.c bar.c - $ mtn commit - $ mtn log bar.c -}}} + $ mtn rename -e foo.c bar.c + $ mtn commit + $ mtn log bar.c ''(-e executes the change in the workspace filesystem as well as in monotone's history)'' ============================================================ --- wiki/Feature/RobustRepository.mdwn 95cf48aeded395db8848c15993dcf85cafbd0f46 +++ wiki/Feature/RobustRepository.mdwn 6afeb7ac2704cb02cee1b50227610af6530f8f42 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/SignedRevisions.mdwn 39be6532825e0c03545be5263107e5c717ba10f0 +++ wiki/Feature/SignedRevisions.mdwn 90c9f380491d7e64bbfb2258e7aa447088a3f97d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -14,11 +14,9 @@ This is a primary and fundamental compon ** -{{{ - $ mtn ... - - $ mtn ... -}}} + $ mtn ... + + $ mtn ... # Further Reference ============================================================ --- wiki/Feature/Symlinks.mdwn eff0776f2e133f6b6869957af5d901cea120f2b3 +++ wiki/Feature/Symlinks.mdwn 88548ea4b993680e83b5cf63b6a080427b36fa63 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/VendorBranches.mdwn 784aad745e2bfce39b6786e3f8b55fa5c8332787 +++ wiki/Feature/VendorBranches.mdwn 76392bfc752e1a954ec9ea0092749b6c9c5e42b9 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/Feature/WebInterface.mdwn ea021a1a917c9a8e8b59fded3a64b796e5acd308 +++ wiki/Feature/WebInterface.mdwn 21cbac8e32b740bfe52d483b598798e02e93ad0a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. ============================================================ --- wiki/FileSystemIssues.mdwn f9d34b769014225c5eadde10398f3f54a2b7fd9c +++ wiki/FileSystemIssues.mdwn fe5294d625288eca796ac795f297f174e8bcd2ba @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # File System Issues in Monotone ============================================================ --- wiki/ForSide.mdwn 49224ef964b59238b37bfd0d54e05684efd0356a +++ wiki/ForSide.mdwn 41936623f8280c15db6c99f3272fc283b65196ca @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ## Please edit system and help pages ONLY in the moinmaster wiki! For more ## information, please see MoinMaster:MoinPagesEditorGroup. ============================================================ --- wiki/FutureCryptography.mdwn 1357ffb4527c1b5530654216fc0a533811a83c92 +++ wiki/FutureCryptography.mdwn e0956367d8b0df160095f502944cd7c5d7a3cb5a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Because of our use of SHA-1, we must make backwards-incompatible changes to our use of cryptography. Since we will be paying the cost of a "flag day", we should consider how to get the most benefit from that cost. ============================================================ --- wiki/Glossary.mdwn 8169c5e85885d58a63b8a72075f53058d9994766 +++ wiki/Glossary.mdwn 4a99fba88b0ce5b5a1a0d47750da612408d5b6fc @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] *This page gives definitions for some of the technical terms and phrases you might come across in the advanced sections of the [http://www.venge.net/monotone/monotone.html manual], on the [http://lists.nongnu.org/mailman/listinfo/monotone-devel monotone list], or in this Wiki.* ============================================================ --- wiki/HistoryBlueSky.mdwn 3a5e4b3e848dde314aead126826edb1ea5ac0946 +++ wiki/HistoryBlueSky.mdwn 6a7f857e0bb6c7f93304f87193502b5b21b935e3 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Space-age things that would be cool to support in our history representation (though not strictly necessary): ============================================================ --- wiki/Hosting.mdwn ab94b4fbf8ced47002785e3ab1cca6c0af890454 +++ wiki/Hosting.mdwn bb7585a980381403debc0a2496f02ecd320dc00c @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] You can easily host monotone anywhere you can run a daemon. With the "dumb server" support, you don't even need that -- all that is required is standard web hosting -- but this option is more experimental, and needs more work to be fully supported (want to help?). ============================================================ --- wiki/HugoMills.mdwn 8b3526ec529983a4ea155558039e70b7fd34807e +++ wiki/HugoMills.mdwn 62d487fcfcf7261f01a9726a73e5a0fb1d486566 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/I18nL10n.mdwn fcf0b74f76b8f4650f020908d54ad1a442400498 +++ wiki/I18nL10n.mdwn 0624dc000a16fd4820948e47b57e52aee17883e2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] i18n and l10n are non-trivial; more so for monotone than for most apps. ============================================================ --- wiki/IPv6.mdwn 48a6666b21c8508128dc100665415a0d50bc1e59 +++ wiki/IPv6.mdwn ef6ced3d38224102acbbd57855b2de9c9f78cfb6 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] IPv6 is a bit tricky. ============================================================ --- wiki/InterfacesFrontendsAndTools.mdwn b65d58e509145238f09d29dc6a4e13b54e7ef2f4 +++ wiki/InterfacesFrontendsAndTools.mdwn 5388646c831aef3b47914eacd1a5129a10fdbcc2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Other programs that work with monotone -- interfaces, frontends and tools ============================================================ --- wiki/JackLloyd.mdwn 9654fecf50faebb942c1011b23edc95ae9d858a6 +++ wiki/JackLloyd.mdwn 2191ace805acbc85f332c9b91af5c83c8aa75d1e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ## Jack Lloyd ============================================================ --- wiki/JustinPatrin.mdwn 5bdcd4e7827982a4e5fd5d2eabb8b586239cc922 +++ wiki/JustinPatrin.mdwn 89ce1745824b310863352dbb392a2b233b77076a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] A user of monotone via the [http://openembedded.org OpenEmbedded] project. Started developing on monotone at the 2007 summit at Google with the net.venge.monotone.ssh-agent branch (see ["MonotoneAndSSHAgent"]). ============================================================ --- wiki/KeystoreFiles.mdwn c0d87637f7942b10723c16d4faa1abfb072a6b54 +++ wiki/KeystoreFiles.mdwn ff51712317ad6d9293ce35852026398a6ea05ff2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] I think the keystore, ~/.monotone/keys, could be more usable. (And this is an area where usability is important for security.) ============================================================ --- wiki/LineEndingMunging.mdwn ec36aadccee4809958f37b1fd85c90c7dddade4d +++ wiki/LineEndingMunging.mdwn 37fadeba70b04e9770e60772cb7351b2904378e8 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] We have to munge line endings in various ways. This is a sad fact, but it seems unavaoidable, so how should we minimize the pain? ============================================================ --- wiki/LocalBadContent.mdwn 6f76d0887b4acdb08b596b78d5aae5fbc38f93f0 +++ wiki/LocalBadContent.mdwn 6b1921231e819ec2627ed6dce8a72e196a266cb6 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format plain #language en ============================================================ --- wiki/LocalSpellingWords.mdwn c33eefbf5615908da497b48b5397c500f698e7d2 +++ wiki/LocalSpellingWords.mdwn 2b646abd5c12ce04fd5ac2e2055369702caa04ed @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] 1st 2nd Abend Checkbox Diffs Guten Haltet Hermann Homepage Info Jürgen Morgen Perl Platt Plattdeutsch Rechtschreibprüfung Spellchecker Zeitstempel ============================================================ --- wiki/LogUI.mdwn d9bc2405923542fb7aead5e99d3dce94920f0c51 +++ wiki/LogUI.mdwn 36a55a58ea5aa67436dcd3065a6fc3202045480a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ## Random Ideas for Improvements of the Log User Interface @@ -6,7 +6,7 @@ * The idea of *additionally* letting the user choose the direction the selected revisions are printed, has been abandoned for now. * (Re-)define the meaning of `--limit`. Printing a maximum number of all ancestors or descendants regardless of their distance to the node in question seems not to be very sensible. What about this: print all members of the next generation, as long as that would not exceed the maximum number of nodes to be printed? * Add a filtering mechanism. Let the user specify `--filter `. Revisions that are matched by the selector will be marked. Other nodes (i.e. merge nodes) are marked according to the unique-* algorithm. All marked nodes will be printed. That way we will retain a sensible graph structure, which is important when printing asciik-style graphs. - * Add some fancy aliases for the filter, like `--stay-on-branch` = `--filter b:currentbranch`. It was noted on the mailing list that you can do this with: {{{mtn auto select b:currentbranch | mtn auto toposort address@hidden | xargs -n 1 mtn log --last 1 --from}}} + * Add some fancy aliases for the filter, like `--stay-on-branch` = `--filter b:currentbranch`. It was noted on the mailing list that you can do this with: `mtn auto select b:currentbranch | mtn auto toposort address@hidden | xargs -n 1 mtn log --last 1 --from` * Add some heuristics for detecting special cases like that: User specifies `--from a --to b` with `a` and `b` being single revisions, but `a` being an ancestor of `b` (so the log would actually be empty). Probably emit a warning and simply exchange `a` and `b`. * *Note to myself:* Check whether `--from h:my-branch --to h:mainline` is actually working. * Some people complain `--from ` being a bit cumbersome to type as opposed to the old `-r`. Is there anything we can do about that? ============================================================ --- wiki/MagicSelectors.mdwn 5903cb1b9ac1d4ca7fa4c6aaeace4c297e08a50e +++ wiki/MagicSelectors.mdwn f9c4f0efd03785edbe2447673adba1775c80665e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] There are a number of interesting problems and use cases where the current selector syntax isn't quite as useful as might be desirable. Various forms of "magic" selectors have been suggested. Some of these allow reasonably basic navigation of parts of the ancestry graph that don't currently have good names, others verge on the truly magical or are useful for very clever selection descriptions. ============================================================ --- wiki/MarcelvanderBoom.mdwn 63df608c4a0b952d19c7773593839904833c8891 +++ wiki/MarcelvanderBoom.mdwn 0dfcfa8a07ff7b80ccf0ed269966c2a80ed97aba @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] :-) ============================================================ --- wiki/MarkusSchiltknecht.mdwn f31820b08fec94a20c7488ae7e111f013d491a7e +++ wiki/MarkusSchiltknecht.mdwn 26854b32cd94cd7bf4408e37d618a926608c126e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/MattJohnston.mdwn bcb146694deff01d56d3879b66b7b2bccac72e64 +++ wiki/MattJohnston.mdwn f1caf9c86542b014ae3618e3271fa7eae94f23c0 @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] Matt Johnston, msh on irc, matt at ucc.asn.au ============================================================ --- wiki/MergeViaWorkingDir.mdwn e514b5c7f268cf67c004f9303d035779014a8032 +++ wiki/MergeViaWorkingDir.mdwn 846e01b7dc491e4aa3e7d6712c6f3a70e616c356 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] *Note: this page is a little out of date, and describes work in progress, not yet visible on mainline. In the mean time, consider using the ZipperMerge pattern to help with difficult merges.* ============================================================ --- wiki/MonotoneAndCVS.mdwn cad35e67ad8d80db34b1b091a01d7d093aa92179 +++ wiki/MonotoneAndCVS.mdwn 4bc49653a62efc5259d46a7aec973772e90be20d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] There are lots and lots of projects out there using CVS. Understandably, they want to stop. We hope they're going to want to use Monotone instead, or use both for a while until they're comfortable with monotone. ============================================================ --- wiki/MonotoneOnDebian.mdwn 0ac72fcc707cac862c04cef732b080ee54eba3f8 +++ wiki/MonotoneOnDebian.mdwn 8929087ed6c41902a42ac46707359a2ab3fab0e0 @@ -1,11 +1,9 @@ -[[tag migration-wip]] +[[tag migration-auto]] # 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 [http://venge.net/monotone website] or the version that is in sid/unstable which is generally kept up to date. -{{{ -apt-get install monotone -}}} + apt-get install monotone # Running a Monotone Server on Debian ============================================================ --- wiki/MtnSummit/2007/AsciikReview.mdwn b53c26b9b646216fb1cce573c9fea3d8648eed22 +++ wiki/MtnSummit/2007/AsciikReview.mdwn e3b3b96193b944245d3abb1f96056677a04601fd @@ -1,56 +1,54 @@ -[[tag migration-wip]] +[[tag migration-auto]] + Always use 'foo const &', not 'const foo &'. (Yes, we're weird.) + + You are not charged by the number of newlines occurring in your code: + asciik::asciik(size_t min_width, ostream & os) : width(min_width), output(os) + --> + asciik::asciik(size_t min_width, ostream & os) + : width(min_width), output(os) + + asciik::draw(const size_t curr_items, const size_t next_items, + const size_t curr_loc, const set > & links, + const set & curr_ghosts, const string & annotation) const + -> + asciik::draw(size_t const curr_items, + size_t const next_items, + size_t const curr_loc, + set > const & links, + set const & curr_ghosts, + string const & annotation) const + + Commas mixed up with initialization are almost always confusing...: + size_t i = link->first, j = link->second, start, end, dot; + -> + size_t i = link->first; + size_t j = link->second; + size_t start, end, dot; + + + Also, be careful to give things the smallest scope possible: + size_t i = link->first, j = link->second, start, end, dot; + if (i == j) + interline[2 * i] = '|'; + else { + ... + } + start, end, dot are only initialized within the 'else' block, so I + freaked out for a moment thinking that we might be forgetting to + initialize them sometimes... but then I verified that they are only + _used_ within the 'else' block, so it was okay. But this would have + been obvious had it been done like: + size_t i = link->first; + size_t j = link->second; + if (i == j) + interline[2 * i] = '|'; + else { + size_t start, end, dot; + ... + } + + (Also, while I'm here, that { on the 'else' is in the wrong place...) + + + Your debugging tweak to charset.cc should be reverted. -{{{ -Always use 'foo const &', not 'const foo &'. (Yes, we're weird.) - -You are not charged by the number of newlines occurring in your code: - asciik::asciik(size_t min_width, ostream & os) : width(min_width), output(os) ---> - asciik::asciik(size_t min_width, ostream & os) - : width(min_width), output(os) - -asciik::draw(const size_t curr_items, const size_t next_items, - const size_t curr_loc, const set > & links, - const set & curr_ghosts, const string & annotation) const --> -asciik::draw(size_t const curr_items, - size_t const next_items, - size_t const curr_loc, - set > const & links, - set const & curr_ghosts, - string const & annotation) const - -Commas mixed up with initialization are almost always confusing...: - size_t i = link->first, j = link->second, start, end, dot; --> - size_t i = link->first; - size_t j = link->second; - size_t start, end, dot; - - -Also, be careful to give things the smallest scope possible: - size_t i = link->first, j = link->second, start, end, dot; - if (i == j) - interline[2 * i] = '|'; - else { - ... - } -start, end, dot are only initialized within the 'else' block, so I -freaked out for a moment thinking that we might be forgetting to -initialize them sometimes... but then I verified that they are only -_used_ within the 'else' block, so it was okay. But this would have -been obvious had it been done like: - size_t i = link->first; - size_t j = link->second; - if (i == j) - interline[2 * i] = '|'; - else { - size_t start, end, dot; - ... - } - -(Also, while I'm here, that { on the 'else' is in the wrong place...) - - -Your debugging tweak to charset.cc should be reverted. -}}} ============================================================ --- wiki/MtnSummit/2007/Funding.mdwn e9d1a4c25cf2417ba32e2e2fa244bc501b601f16 +++ wiki/MtnSummit/2007/Funding.mdwn 2834c6d8a1b5b2097558f0a0d22e1fef3991d8d1 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # People requesting funding ============================================================ --- wiki/MtnSummit/2007/Gibberish.mdwn 26238ad7803129af272a0a085cadab948b9164e0 +++ wiki/MtnSummit/2007/Gibberish.mdwn 5ea8995dcbd984c719d21e86934329f6ae74beb5 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] * no cornflakes at the restaurant * sixth period ============================================================ --- wiki/MtnSummit/2007/Ideas.mdwn 06e80157712ceef45bd1e3f8d70e502386f8bb95 +++ wiki/MtnSummit/2007/Ideas.mdwn 56a30d0bc0a02a5231e027a1f798003a84d3c481 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Brainstorming ideas to be worked on at the MtnSummit2008 (or in general, really!): ============================================================ --- wiki/MtnSummit/2007/InterestAndDates.mdwn 13ed055222d9e31afaa81d9ec3fae360b082bb7e +++ wiki/MtnSummit/2007/InterestAndDates.mdwn ecb464dede872abda0e0de3e433c87053f5d159f @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The idea of holding some sort of sprint has come up. (I.e., getting a bunch of us together to hack like mad.) To better explore the idea, put a note here if you might be interested in attending, and where you are: ============================================================ --- wiki/MtnSummit/2007/LogisticsNA.mdwn 795773c41d1565600c9df1fc74571d8e3592cd32 +++ wiki/MtnSummit/2007/LogisticsNA.mdwn 05a41595687f8306615af40a1f41e94191b5de4a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Logistics for Mtn Summit 2007 (North American edition) ============================================================ --- wiki/MtnSummit/2007/Notes.mdwn 40c33a59e74d92b7ae791bc409aa2685ceeb42a4 +++ wiki/MtnSummit/2007/Notes.mdwn e033091476473292369f982386811109c6d3da33 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Done ============================================================ --- wiki/MtnSummit/2007/Rooms.mdwn 33c00fccf312d672d9c9fb44dfc81f257390fba6 +++ wiki/MtnSummit/2007/Rooms.mdwn 37a4e4e4b7ab06e3e060e49beafc616b46bf7d37 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] We have until January 20 to book rooms at our special rate. This page is to help us figure out roommates and such things. Each room is booked for a particular amount of time, by a particular person -- this is the person that calls the hotel and uses their own credit card. Other people probably want to stay with them too to split costs, but the hotel doesn't care about that (just the number staying in the room), so we have to arrange it separately... ============================================================ --- wiki/MtnSummit/2007/Schedule.mdwn cbbb9e357a270bf8e0e2e1d89524aa37daaba4e9 +++ wiki/MtnSummit/2007/Schedule.mdwn 917925aa0747cfd410716067e6e5fc2e41e0df69 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Earlier ============================================================ --- wiki/MtnSummit/2007.mdwn f1044e55b7e35a0462c84a2305cf3fea1066fb12 +++ wiki/MtnSummit/2007.mdwn 2ec19cb36538dc5e0c4ddc54bcf5debb19598c5f @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] We are holding a sprint! Or sprints. Or something. Anyway, we're getting as many of us together as we can, to hack like mad. Would you like to come too? ============================================================ --- wiki/MtnSummit/2008/Branches.mdwn 4624d81fad4a17d69424573f0263c9ee561a111b +++ wiki/MtnSummit/2008/Branches.mdwn b1ea00060a74dbac4f14a7e793f343620b77bd69 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The branches which we've worked upon on the 2008 summit and which should be reviewed by others: ============================================================ --- wiki/MtnSummit/2008.mdwn b81793864edb6e40c98b755ef468441ca81b03a5 +++ wiki/MtnSummit/2008.mdwn b343ea00bb3abe4cc9e26931268d8a8c2fdd4d4b @@ -1,18 +1,18 @@ -[[tag migration-wip]] +[[tag migration-auto]] We're planning to hold another MtnSummit, in early 2008, this time in Europe! ["MtnSummit/Ideas"] lists many ideas we collected for last years summit, but weren't able to complete. If you have more to wishes, make sure to add them there. -=== How Can I attend? === +### How Can I attend? Our bar is strict but low: if you're willing to work, you're welcome to come. Even if you haven't worked with monotone source before, we'll help you get started -- or help with the docs, or testing... plenty of work for everyone. To show your interest, put your name below and indicate what dates might work for you. -= time = +# time The offical summit is from April 28, 10:00 until May 4, 19:00. -= location = +# location Technologiezentrum Wuppertal W-tec GmbH Lise-Meitner-Straße 1-9 @@ -22,22 +22,22 @@ Room number is 3.1 (third floor). Because we are only so few, we must into another house; now it is house 1 (first building on the left side of the street). Room number is 3.1 (third floor). -= directions = +# directions -=== from airport Düsseldorf (DUS) to Wuppertal main station === +### from airport Düsseldorf (DUS) to Wuppertal main station * costs 9,10 Euro, ticket "Preisstufe C" valid for train and bus * take train to "Düsseldorf Hauptbahnhof" (main station) * take train "S8" from platform no 9 3/4 to "Wuppertal Hauptbahnhof" (main station) -=== from airport Düsseldorf-Weeze (NRN) to Wuppertal main station === +### from airport Düsseldorf-Weeze (NRN) to Wuppertal main station * costs 18.10 EUR, a ticket in the so-called "NRW-Tarif", which allows you to use a bus or tram to resp. from the first/last train station * 2h on weekdays, 2.5h in weekend -=== from airport Frankfurt (FRA) to Wuppertal main station === +### from airport Frankfurt (FRA) to Wuppertal main station * costs 46-67 Euro, depending on used train * 1.5-3 h, depending on used train -=== Wuppertal main station to w-tec === +### Wuppertal main station to w-tec * costs 2.10 Euro, ticket "Preisstufe A" (you don't need this, if you have ticket "Preisstufe C" from DUS, or a ticket in the "NRW-Tarif" ), four tickets cost 7.40 Euro * go through the tunnel to bus platform no. 6 * take bus no. 603 direction "Schulzentrum Süd" or bus no. 625 direction "Berghausen" @@ -46,18 +46,18 @@ Room number is 3.1 (third floor). * w-tec, because we are only so few, we must into another house; now it is house 1 (first building on the left side of the street) * follow the signs to the company NETfinish [http://netfinish.de logo] -= earlier arrival / later departure = +# earlier arrival / later departure -=== food === +### food it's up to you, nothing organized at the moment The university mensa of Campus Freudenberg is 5 minutes from there, has excellent vegeterian food for 3.60 Euro (1.80 Euro proven students) (On weekdays, note that 1st of May is a public holiday in Germany.) -=== beds === +### beds * earlier arrival is possible from april 25 (Friday) late in the evening * later departure is possible until may 11 (Sunday) -= people = +# people ||name ||email||mobile phone|| arrival|| departure|| airport|| funding needed? || comments (food allergy)|| ||Siegfried Herbold||mtnsummit herbold info|| +49 160 97949444|| Apr 25, 20:00|| --- ||by car|| no || || ||Lapo Luchini|| address@hidden || +39 347 2270475 || Apr 24 evening in Düsseldorf, Apr 27 late evening in Wuppertal || May 4, 20:21 Wuppertal Hbf || by train || no || 25-27 my girlfriend will be present and we're mainly interested in Düsseldorf sightseeing, then I'll reach Wuppertal alone || @@ -68,7 +68,7 @@ The university mensa of Campus Freudenbe ||Daniel Carosone||dan geek com au || ||Apr 26 12:05 || May 5||DUS || || May spend some time sightseeing around DUS after arrival until evening of 27th, especially if others are interested in doing same. || ||template line|| || || || || || || || -= schedule = +# schedule Apr 28, first official day of summit ||~10:00|| first official meeting @ w-tec with breakfast|| ||14:00|| lunch @w-tec|| @@ -81,23 +81,23 @@ Note that the 1st of May is a public hol Note that the 1st of May is a public holiday in Germany (Jesus' Ascension and May Day). -= local costs = +# local costs * local transport for whole week ~30 Euro * food for whole week ~100 Euro * beer <1000 Euro -= expected temperature range = +# expected temperature range 14°C +/-8 °C (= 57°F +/- 14°F for metric impaired) -= take with you = +# take with you * laptop * lan-cable * power adaptor for germany (230V, 50Hz) * multiple socket (if you need more than one device) * brain, fast fingers -= sightseeing = +# sightseeing * Cologne ( especially the cathredral (Dom) http://www.koelner-dom.de/ ) * Düsseldorf ( http://www.duesseldorf.de/en/index.shtml ) * Schwebebahn overhead train ( http://www.schwebebahn-wtal.de/ ) ============================================================ --- wiki/MtnSummitWishes.mdwn 6091a916665165d609749b049a469e4aea45a01d +++ wiki/MtnSummitWishes.mdwn 431e08e0daefac95070a81da9a88ffe1b49f92ad @@ -1,3 +1,3 @@ -[[tag migration-wip]] +[[tag migration-auto]] #REDIRECT MtnSummit/Ideas ============================================================ --- wiki/MultiParentWorkspaceFallout.mdwn b6c941ff593277e86d44fb76704882196cdaabd2 +++ wiki/MultiParentWorkspaceFallout.mdwn 8aaecede2b97e136135d5a710e8f80554b0930b9 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Some commands needed modification to do something sensible in a multi-parent workspace. Here I've categorized all of the documented commands (i.e. those visible in mtn --help) with some notes on what changed and why. @@ -34,64 +34,62 @@ Starred commands in the list below will Starred commands in the list below will have their semantics change later in this process, but are not affected at the present stage. + approve + automate ancestors + ancestry_difference + certs + children + common_ancestors + descendents + erase_ancestors + get_file + graph + heads + interface_version + keys + leaves + packet_for_fdata + packet_for_fdelta + packet_for_rdata + packets_for_certs + parents + stdio + tags + toposort + cat + cert + checkout + comment + chkeypass + complete + cvs_import + db (all) + disapprove + dropkey + explicit_merge (*) + fdiff + fload + fmerge + genkey + heads + help + identify + list certs/keys/branches/epochs/tags/vars + merge (*) + merge_into_dir (*) + privkey + propagate (*) + pubkey + pull + push + rcs_import + read + serve + setup + set + show_conflicts (*?) + sync + tag + testresult + trusted + unset -{{{ - approve - automate ancestors - ancestry_difference - certs - children - common_ancestors - descendents - erase_ancestors - get_file - graph - heads - interface_version - keys - leaves - packet_for_fdata - packet_for_fdelta - packet_for_rdata - packets_for_certs - parents - stdio - tags - toposort - cat - cert - checkout - comment - chkeypass - complete - cvs_import - db (all) - disapprove - dropkey - explicit_merge (*) - fdiff - fload - fmerge - genkey - heads - help - identify - list certs/keys/branches/epochs/tags/vars - merge (*) - merge_into_dir (*) - privkey - propagate (*) - pubkey - pull - push - rcs_import - read - serve - setup - set - show_conflicts (*?) - sync - tag - testresult - trusted - unset -}}} ============================================================ --- wiki/NonMergeConflicts.mdwn 236af559f86750d19177f0caca3304bfae6ca5ff +++ wiki/NonMergeConflicts.mdwn 8ade4ea021be0dcb1159f1d712cac552ea4f522e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Conflicts -- they're not just for merges anymore! ============================================================ --- wiki/NotesOnTestingChangesetify.mdwn 3d921d92e8493522c57302360e9154b766ac4ee0 +++ wiki/NotesOnTestingChangesetify.mdwn 97c77d96cf528356e24485755aada4d62726b2ed @@ -1,17 +1,17 @@ -[[tag migration-wip]] +[[tag migration-auto]] The procedure for migration from pre-0.16 databases ("changesetify") is currently not tested by the automatic testsuite. This is partially because there's pretty good odds that there are no such databases remaining in use (so it doesn't matter if the code works) and partially because generating the necessary database dumps is not easy. -I (Zack) recently attempted to construct such a dump, because I wrote code to discard the obsolete database tables ({{{manifest_certs}}}, {{{manifest_deltas}}}, and {{{manifests}}}) used by pre-roster monotone, and I wanted to make absolutely sure that this code did not destroy data needed to complete a changesetification. (This is partially, but not completely, tested by the existing {{{schema_migration_with_rosterify}}} test case; that test only contains post-changesetify, pre-rosterify test cases, and those use only the {{{manifest_deltas}}} and {{{manifests}}} tables.) Forthwith some notes on just what has to be done. +I (Zack) recently attempted to construct such a dump, because I wrote code to discard the obsolete database tables (`manifest_certs`, `manifest_deltas`, and `manifests`) used by pre-roster monotone, and I wanted to make absolutely sure that this code did not destroy data needed to complete a changesetification. (This is partially, but not completely, tested by the existing `schema_migration_with_rosterify` test case; that test only contains post-changesetify, pre-rosterify test cases, and those use only the `manifest_deltas` and `manifests` tables.) Forthwith some notes on just what has to be done. - 1. The appropriate version to use to construct a test case is monotone 0.14. Versions 0.15 and 0.16 came out in the *middle* of the changeset transition, and have interesting bugs that we don't want to deal with. Unfortunately, the code at {{{t:monotone-0.14}}} requires patches to compile with gcc 4.1 and boost 1.33. The patches are at the bottom of this page. - 1. The code for constructing a test repository (from {{{tests/schema_migration}}}) uses mtn features that did not exist in 0.14: - * The {{{attr}}} commands. It is necessary to translate these to manipulations of {{{.mt-attr}}}, which is how attributes used to be done. (Note that {{{schema_migration_with_rosterify}}} does not attempt to test attribute migration - which is worrisome, as that is a major part of the roster transition.) - * The {{{--message-file}}} option is not present, and putting the message on the command line does not appear to work. - * It is not clear whether the {{{--date}}} option works. It is accepted for {{{commit}}}, but not {{{propagate}}}. - * monotone 0.14 wants {{{[pubkey]}}} and {{{[privkey]}}} packets instead of {{{[keypair]}}} packets. I do not know how to convert the latter to the former. I snarfed the key out of 0.14's {{{testsuite.at}}} instead, but I'm not sure it's the same one. - 1. There might be an outright bug in the code to generate test databases: {{{testfile2}}} is added, then we revert to a revision in which it didn't exist, *modify it*, and check in another revision without adding it again. Is that intentional? - 1. If you bull your way past all of that, you get a database, which you can dump with the old version, reload with the new one, and run through {{{db migrate}}}. Then you get this from {{{db changesetify}}}: {{{mtn: rebuilding revision graph from manifest certs + 1. The appropriate version to use to construct a test case is monotone 0.14. Versions 0.15 and 0.16 came out in the *middle* of the changeset transition, and have interesting bugs that we don't want to deal with. Unfortunately, the code at `t:monotone-0.14` requires patches to compile with gcc 4.1 and boost 1.33. The patches are at the bottom of this page. + 1. The code for constructing a test repository (from `tests/schema_migration`) uses mtn features that did not exist in 0.14: + * The `attr` commands. It is necessary to translate these to manipulations of `.mt-attr`, which is how attributes used to be done. (Note that `schema_migration_with_rosterify` does not attempt to test attribute migration - which is worrisome, as that is a major part of the roster transition.) + * The `--message-file` option is not present, and putting the message on the command line does not appear to work. + * It is not clear whether the `--date` option works. It is accepted for `commit`, but not `propagate`. + * monotone 0.14 wants `[pubkey]` and `[privkey]` packets instead of `[keypair]` packets. I do not know how to convert the latter to the former. I snarfed the key out of 0.14's `testsuite.at` instead, but I'm not sure it's the same one. + 1. There might be an outright bug in the code to generate test databases: `testfile2` is added, then we revert to a revision in which it didn't exist, *modify it*, and check in another revision without adding it again. Is that intentional? + 1. If you bull your way past all of that, you get a database, which you can dump with the old version, reload with the new one, and run through `db migrate`. Then you get this from `db changesetify`: {{{mtn: rebuilding revision graph from manifest certs mtn: certs in | certs out | nodes | revs out mtn: 28 | 0 | 5 | 0 mtn: scanning for bogus merge edges ============================================================ --- wiki/OldTestHarnessIssues.mdwn ae22459256e7946bf5b746c6f5eba6c8fa0ea748 +++ wiki/OldTestHarnessIssues.mdwn 0f26c25d30e5e3d2e48267658b965cf0f798b912 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Nice things about autotest: * every test gets run in its own little scratch directory ============================================================ --- wiki/OneBranchPerDbForServe.mdwn 1a067c2618da87eee77e03d0b89446bd6cb45ccc +++ wiki/OneBranchPerDbForServe.mdwn d029b6ab0516bb8afd2353d7d0e27bde59389f89 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] If you have a lot of big branches (maybe you need to version control a library of some sort), you can get a large db file. sqlite and monotone are paranoid about data integrity, but it is possible that a hardware failure during an operation can hose parts of the database. ============================================================ --- wiki/PartialPull.mdwn f88802944b7ca0efc5be21471a92712e74f1a81e +++ wiki/PartialPull.mdwn 8a3513572c00a6088f14acab5921316c97cfa83f @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] In order to store or use a revision, monotone currently requires the complete ancestry of the revision to also be in the local database. Whenever a revision is sent as part of a pull, all of its ancestors are sent too if they're not already at the receiver. @@ -10,7 +10,7 @@ We use the term *Partial Pull* to refer # Implementation details - - Missing revisions are represented by a horizon. The horizon is generated from the initial partial pull request and stored as a list of nodes which are the first (most recent) ones missing. See table {{{sentinels}}} + - Missing revisions are represented by a horizon. The horizon is generated from the initial partial pull request and stored as a list of nodes which are the first (most recent) ones missing. See table `sentinels` - For the initial partial pull we need an additional option to send to the other host which indicates that only a subset of the revisions are going to get synchronized. For subsequent synchronizations you would have to tell the other side about the horizon. Using this information both sides can construct a decent merkle tree for synchronization. @@ -18,7 +18,7 @@ We use the term *Partial Pull* to refer # Plan to implement it -Table with horizon/fake nodes will be called {{{sentinels}}} (unique indexed set). You have to test for members of this set as well as for the empty revision. +Table with horizon/fake nodes will be called `sentinels` (unique indexed set). You have to test for members of this set as well as for the empty revision. See the following graph [http://home.wtal.de/petig/Mtn/PartialPull.svg SVG] http://home.wtal.de/petig/Mtn/PartialPull.png : @@ -45,14 +45,12 @@ The important question is what exactly t # More comments from njs The important question is what exactly the horizon looks like. Here's a graph: -{{{ - A B C - \ / \ / ---------------------- horizon - \ / \ D - E \ / - F -}}} + A B C + \ / \ / + --------------------- horizon + \ / \ D + E \ / + F Important facts: * For purposes of netsync, we have all versions that are descendents of the set: D E. ============================================================ --- wiki/PaulCrowley.mdwn 0946669a557a94542bb3b3e599d10620ac56d707 +++ wiki/PaulCrowley.mdwn af2f3f4c0f52612fab89e4cbf7c46f07f964f97e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Cryptography guy. This summit will be my first time coding for Monotone. ============================================================ --- wiki/People.mdwn 6c9ec129ad4cf8e304b07e123668899e685101eb +++ wiki/People.mdwn 1b7c67dfcf9c40a48a8a5f82250cb2636bad0210 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page will introduce some of the members of the monotone development team, their responsibilities and their contact data i.e. IRC nick. See also: http://www.frappr.com/monotone ============================================================ --- wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn 43f9b4893ad690d7ffe613a73504241af1a01906 +++ wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn 1426d71fba4f82d540913ca2264c7007c9ac1e1b @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Ever since we imported SQLite 3.2.3 (which included a much improved query optimizer, and added the [http://sqlite.org/lang_analyze.html analyze] command), we've needed to run an analyze on monotone repositories to get decent performance, otherwise SQLite doesn't make good use of our indices and we become extremely I/O bound. This can affect many areas of monotone--for instance, a small commit into a very large repository can take an extremely long time unless the repository has been analyzed recently, because we spend many minutes seek()ing in the repository. ============================================================ --- wiki/PerformanceWork.mdwn 7734b29157885158904bdacc0e9651a5f3d97736 +++ wiki/PerformanceWork.mdwn 6dc38f35ed590ab003cafc53a76c7cc892ec6bad @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Several key operations are still prohibitively slow in monotone. @@ -10,17 +10,13 @@ Also discussion at http://colabti.org/ir Also discussion at http://colabti.org/irclogger/irclogger_log/monotone?date=2006-01-31,Tue&sel=#l13 for ideas. -{{{ -pull has gotten far faster in 0.26+, and again in 0.30 - but it is still too slow for very large histories -}}} + pull has gotten far faster in 0.26+, and again in 0.30 - but it is still too slow for very large histories ## annotate Annotate is really too slow to be used. Investigation underway in net.venge.monotone.annotate branch of storing per-file revision DAG in the database as well to avoid parsing all revision rosters out of db while doing history traversal. -{{{ -annotate has gotten much faster in 0.32, and again in 0.33, and should be quite usable now. It is still slow when compared to other systems, though. -}}} + annotate has gotten much faster in 0.32, and again in 0.33, and should be quite usable now. It is still slow when compared to other systems, though. ## restricted log @@ -28,18 +24,14 @@ Restricted log in backwards direction (f Restricted log in backwards direction (from newer to older revisions) can already be made much faster by exploiting the roster markings. (The markings hold interesting revision ids per file, i.e. revisions where the file was born, or changed it contents, name, or attributes.) However, for this to work properly, the traversal alogorithm used by the log command has to be fixed. Currently it does not always visit nodes in topological order. -{{{ -restricted log (in backwards direction) has gotten much faster in 0.32, exploiting the markings and revision heights. -}}} + restricted log (in backwards direction) has gotten much faster in 0.32, exploiting the markings and revision heights. ## update on a workspace with a large history/number of files Updating a large tree sometimes seems to take a good amount of time on a large tree and/or workspace. Finding the branch and revision to update seems to take an inordinate amount of time. -{{{ -"mtn up" on an OpenEmbedded database can take 80s or more to output "updating along branch xxx". That seems an awfully long time to figure out the branch of the current checkout. Selecting the output target and actually updating was 5-10s more. During the initial 80s my CPU was mostly waiting for IO so it seems most if not all of the 100MB DB was being read into memory. -}}} + "mtn up" on an OpenEmbedded database can take 80s or more to output "updating along branch xxx". That seems an awfully long time to figure out the branch of the current checkout. Selecting the output target and actually updating was 5-10s more. During the initial 80s my CPU was mostly waiting for IO so it seems most if not all of the 100MB DB was being read into memory. This has been traced to a number of sources, and should have improved **significantly** in monotone 0.30. ============================================================ --- wiki/PieceCache.mdwn ba54ba6fc2223670fce9e77761b5b00fd7f71f6c +++ wiki/PieceCache.mdwn b5302dfae430e0cd4e135a60977f7811714c462b @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] For xdelta reconstruction in the db layer, we really should use a piece cache instead of our current full-version cache (see `vcache` in database.cc). Not only would it just work better, but it would have much nicer properties for more clever delta handling. For instance, if we switched to forward deltas for files, we would need something like this to make backwards iteration through a file's history to be fast (like 'annotate' does), and it would naturally let us send deltas off the wire straight to disk without reconstructing in memory. @@ -8,121 +8,111 @@ We use a single structure to hold both t We use a single structure to hold both the delta text unique to a file, and the extents necessary to reconstruct the file from its delta text, plus the delta text of its precursors. Another approach might be to split these two parts into two different structures. The current approach assumes that in general the extents will be relatively small (which may be false, since each extent is ~20 bytes, assuming 64 bit size_t, and in general each delta in a chain has at least one more extent than its base does), and so it is not generally useful to be able to throw away extent information independent of text information. (Text information is generally pinned in memory so long as *any successor* is recently used, while extent information is only need to reconstruct this particular file, or to apply a new delta to this particular file.) -{{{ -size_t total_space_used_for_file_cache = 0; -std::map loaded_files; + size_t total_space_used_for_file_cache = 0; + std::map loaded_files; + + struct File + { + file_id fid; + std::string text; // in practice, a file or file + shared_ptr precursor; // may be null + size_t memory_size; // size used by this object, plus precursor->size, + // i.e., total memory needed to keep this file accessible + struct Extent + { + // this structure represents an extent in some File's 'text' member + File * source; // not a shared_ptr, because may point to 'this' (causing a + // reference loop), and the 'precursor' shared_ptr recursively + // pins all precursors in memory anyway. + size_t offset; + size_t length; // could make this length_of_this_file_after_adding_this_extent, + // to allow binary search during patch combination... + }; + std::vector extents; + }; + + size_t + File::calc_this_size() + { + return sizeof(File) + this->text.size() + (sizeof(Extent) * this->extents.size()); + } + + void + File::init_memory_size() + { + size_t precursor_size = (precursor ? precursor->memory_size : 0); + size_t this_size = this->calc_this_size(); + ::total_space_used_for_file_cache += this_size; + this->memory_size = this_size + precursor_size; + } + + File::File(file_id fid, file text) + : fid(fid), text(text()), precursor(0); + { + Extent e; + e.source = this; + e.offset = 0; + e.length = this->text.size(); + extents.reserve(1); + extents.push_back(e); + this->init_memory_size(); + safe_insert(loaded_files, std::make_pair(this->fid, this)); + } + + File::File(file_id fid, shared_ptr base, file d) + : fid(fid), text(d()), precursor(base) + { + // fill in the extents structure, using base->extents + parse_delta(d, *base, *this, this->extents); + this->init_memory_size(); + safe_insert(loaded_files, std::make_pair(this->fid, this)); + } + + File::~File() + { + ::total_space_used_for_file_cache -= this->calc_this_size(); + safe_remove(loaded_files, this->fid)); + } -struct File -{ - file_id fid; - std::string text; // in practice, a file or file - shared_ptr precursor; // may be null - size_t memory_size; // size used by this object, plus precursor->size, - // i.e., total memory needed to keep this file accessible - struct Extent - { - // this structure represents an extent in some File's 'text' member - File * source; // not a shared_ptr, because may point to 'this' (causing a - // reference loop), and the 'precursor' shared_ptr recursively - // pins all precursors in memory anyway. - size_t offset; - size_t length; // could make this length_of_this_file_after_adding_this_extent, - // to allow binary search during patch combination... - }; - std::vector extents; -}; - -size_t -File::calc_this_size() -{ - return sizeof(File) + this->text.size() + (sizeof(Extent) * this->extents.size()); -} - -void -File::init_memory_size() -{ - size_t precursor_size = (precursor ? precursor->memory_size : 0); - size_t this_size = this->calc_this_size(); - ::total_space_used_for_file_cache += this_size; - this->memory_size = this_size + precursor_size; -} - -File::File(file_id fid, file text) - : fid(fid), text(text()), precursor(0); -{ - Extent e; - e.source = this; - e.offset = 0; - e.length = this->text.size(); - extents.reserve(1); - extents.push_back(e); - this->init_memory_size(); - safe_insert(loaded_files, std::make_pair(this->fid, this)); -} - -File::File(file_id fid, shared_ptr base, file d) - : fid(fid), text(d()), precursor(base) -{ - // fill in the extents structure, using base->extents - parse_delta(d, *base, *this, this->extents); - this->init_memory_size(); - safe_insert(loaded_files, std::make_pair(this->fid, this)); -} - -File::~File() -{ - ::total_space_used_for_file_cache -= this->calc_this_size(); - safe_remove(loaded_files, this->fid)); -} -}}} - Our cache per se consists of an LRU cache of shared_ptr's. The idea is that instead of LRU'ing the File's directly, which would cause problems because of the dependency chains between them, we LRU 'pins' -- each time we remove a pin from the LRU, we reduce a File's reference count. When we need to reduce the cache size, we repeatedly remove pins until, eventually, things begin falling out of memory, and eventually enough falls out that we reach our low-water mark and can stop unpinning things. Example: `annotate` with forward deltas: loading the latest version pulls all the older versions (back to the last full text) into the cache. Walking the chain backwards is free (until we fall off the fulltext and have to load the next chain segment), and only the already-walked parts of the chain can fall out of memory. Example: initial `pull` with forward deltas: the last-inserted version is there in memory, so it's very cheap to insert the forward delta from the wire and validate it. Additionally, some number of files behind the last one received remain in memory, and these are the ones that are most likely to be jumped to when there was divergence. E.g., if we have -{{{ - A - | - B - |\ - C E - | - D -}}} + A + | + B + |\ + C E + | + D received in alphabetical order, then likely the B `File` will still be in memory when E is received, though A may have dropped out. ## Algorithms Fetching a file: -{{{ - walk delta graph backwards to find either a full-text on disk, or an already cached `File` - walking forwards, load each delta into a File, manually keeping each in memory until the next refers to it - when we reach the desired file: - ensure the LRU's high-water mark is larger than my_file->memory_size - pin my_file in the LRU cache - reconstruct the text - check the SHA1 - return it -}}} + walk delta graph backwards to find either a full-text on disk, or an already cached `File` + walking forwards, load each delta into a File, manually keeping each in memory until the next refers to it + when we reach the desired file: + ensure the LRU's high-water mark is larger than my_file->memory_size + pin my_file in the LRU cache + reconstruct the text + check the SHA1 + return it Inserting a full-text given a good base: -{{{ - fetch the base as above - make_delta(base, new) - insert the delta as below -}}} + fetch the base as above + make_delta(base, new) + insert the delta as below Inserting a delta directly: + ensure the base is loaded into the cache, as in 'Fetching a file' + create a File for the new delta + verify its SHA1, by reading off the extent list directly into SHA1 + (no need to reconstruct the file in a chunk of linear memory) + optionally, use the new File's memory_size as a clue to whether we + should insert it as a full-text breaking the chain (or use some + other heuristic more closely tied to disk access costs) + bump the LRU's high-water mark to larger than the new file's memory size + pin the new file + write it to the db -{{{ - ensure the base is loaded into the cache, as in 'Fetching a file' - create a File for the new delta - verify its SHA1, by reading off the extent list directly into SHA1 - (no need to reconstruct the file in a chunk of linear memory) - optionally, use the new File's memory_size as a clue to whether we - should insert it as a full-text breaking the chain (or use some - other heuristic more closely tied to disk access costs) - bump the LRU's high-water mark to larger than the new file's memory size - pin the new file - write it to the db -}}} ============================================================ --- wiki/ProjectsUsingMonotone.mdwn acdda58a620edaa6fe2f74aa6cee4e32f3b612ea +++ wiki/ProjectsUsingMonotone.mdwn ebbb7ea394c1e6d772c3fcf2a74ccdcd6e54ad04 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] A number of projects use monotone. Some of them are listed here. ============================================================ --- wiki/QuickieTasks.mdwn 61c008a59f664e98a3a8d533fc5f1db70f4a7683 +++ wiki/QuickieTasks.mdwn 04d9663c47a897fcb46839834e65c9ecbb062c6d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # quickie tasks ============================================================ --- wiki/RelativePathnames.mdwn 692ce2f3610ebf2be4dce521dd9d0a99da937811 +++ wiki/RelativePathnames.mdwn 510d6366539b3ee80ed8724ef66959404b09252d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ## Relative Pathnames @@ -7,79 +7,69 @@ For those situations, the following is a ### mtnpwd For those situations, the following is a simple `mtnpwd` script which prints the current working directory relative to the project root. -{{{ -#!/bin/sh -mtndir="" -while [ "$PWD" != '/' ]; do - [ -d _MTN ] && echo "$mtndir" && exit 0 - if [ -n "$mtndir" ]; then - mtndir="`basename $PWD`/$mtndir" - else - mtndir="`basename $PWD`" - fi - cd .. 2> /dev/null || break -done -echo "Not in a monotone project; no _MTN dir found." >&2 -exit 255 -}}} + #!/bin/sh + mtndir="" + while [ "$PWD" != '/' ]; do + [ -d _MTN ] && echo "$mtndir" && exit 0 + if [ -n "$mtndir" ]; then + mtndir="`basename $PWD`/$mtndir" + else + mtndir="`basename $PWD`" + fi + cd .. 2> /dev/null || break + done + echo "Not in a monotone project; no _MTN dir found." >&2 + exit 255 For example: -{{{ -$ mtn --db=test.mtn setup -b com.example.test -$ mkdir -p foo/bar/baz -$ cd foo/bar/baz -$ mtnpwd -foo/bar/baz -}}} + $ mtn --db=test.mtn setup -b com.example.test + $ mkdir -p foo/bar/baz + $ cd foo/bar/baz + $ mtnpwd + foo/bar/baz And of course from there it is easy (assuming `sed` is GNU `sed`) to print the project root relative to the current working directory: -{{{ -$ mtnpwd | sed -e 's/[^/]\+/../g' -../../.. -}}} + $ mtnpwd | sed -e 's/[^/]\+/../g' + ../../.. ### known Finally, here is a script called `known` which prints the output of `mtn list known` with paths made relative to the current directory. As an added benefit, it allows one to filter out files or directories, so that the output may be piped directly into commands which expect filenames of a particular type: -{{{ -#!/bin/sh -mtndir=`mtnpwd` || exit $? -if [ -n "$mtndir" ]; then - mtnrel="$(echo $mtndir | sed -e 's/[^/]\+/../g')/" -fi -if [ "$1" = '-h' -o "$1" = '--help' ]; then - echo "usage: `basename $0` [-a|-d] PATH..." - echo " -a list files and directories" - echo " -d list only directories" - echo " otherwise, lists only files" - exit 255 -fi -if [ "$1" = "-a" ]; then - dirs=true - files=true - shift -elif [ "$1" = "-d" ]; then - dirs=true - files=false - shift -else - dirs=false - files=true -fi + #!/bin/sh + mtndir=`mtnpwd` || exit $? + if [ -n "$mtndir" ]; then + mtnrel="$(echo $mtndir | sed -e 's/[^/]\+/../g')/" + fi + if [ "$1" = '-h' -o "$1" = '--help' ]; then + echo "usage: `basename $0` [-a|-d] PATH..." + echo " -a list files and directories" + echo " -d list only directories" + echo " otherwise, lists only files" + exit 255 + fi + if [ "$1" = "-a" ]; then + dirs=true + files=true + shift + elif [ "$1" = "-d" ]; then + dirs=true + files=false + shift + else + dirs=false + files=true + fi + + mtn list known $* | while read f; do + r="$mtnrel$f" + [ -e "$r" ] || continue + [ -f "$r" ] && ! $files && continue + [ -d "$r" ] && ! $dirs && continue + echo $r + done + exit 0 -mtn list known $* | while read f; do - r="$mtnrel$f" - [ -e "$r" ] || continue - [ -f "$r" ] && ! $files && continue - [ -d "$r" ] && ! $dirs && continue - echo $r -done -exit 0 -}}} - For example (assuming both `mtnpwd` and `known` are in the `PATH`): -{{{ -$ known | xargs etags -}}} + $ known | xargs etags builds the `TAGS` file from any directory in a source tree. ============================================================ --- wiki/ReleaseBranchPattern.mdwn 7da38dacfada27acb510147207fefc0b0c30979c +++ wiki/ReleaseBranchPattern.mdwn bfd999cc20436a9d65f7db08195f6ff92c99f70c @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ### When to Use ============================================================ --- wiki/RevertUI.mdwn 43e2d1517696a780ae13fac22f9d83be1e9aa8ff +++ wiki/RevertUI.mdwn e042b4274b04fa6aeb6b914b099be99927bc4b84 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] People have complained that the current behavior of "revert" is dangerous: http://article.gmane.org/gmane.comp.version-control.monotone.devel/5478 ============================================================ --- wiki/RevisionNumbering.mdwn f7700c3a50756659f82c390f36735b53322957cc +++ wiki/RevisionNumbering.mdwn 2bc8e462f05949afbd96bd3a57f995b9efeec8b0 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Motivation @@ -27,36 +27,32 @@ sorting them according to their heights. Now, if you have a set of revisions, you can topologically sort them by simply sorting them according to their heights. This is not more expensive than an integer sort and depends only on the size of the set you are sorting. -{{{ - A 0 - /|\ /|\ - B C D 1 1 1 - | |/ \ | |/ \ - | E | | 2 | - |/ \ | => |/ \ | - F G | 3 3 | - | |/ | |/ - H I 4 4 - : : : : -}}} + A 0 + /|\ /|\ + B C D 1 1 1 + | |/ \ | |/ \ + | E | | 2 | + |/ \ | => |/ \ | + F G | 3 3 | + | |/ | |/ + H I 4 4 + : : : : ## Criticism The ordering created by that algorithm doesn't always keep linear chains of revisions together. Instead, parallel running branches are zipped together in way that makes this sorting quite unusable e.g. for log output. -{{{ - A 0 - / \ / \ - B C 1 1 - | | | | - D E => 2 2 - | | | | - F G 3 3 - \ / \ / - H 4 -}}} + A 0 + / \ / \ + B C 1 1 + | | | | + D E => 2 2 + | | | | + F G 3 3 + \ / \ / + H 4 -A topological sort of this graph's nodes according to their heights yields {{{ABCDEFGH}}} which is - at least for log output - highly undesirable. We want either {{{ABDFCEGH}}} or {{{ACEGBDFH}}}. +A topological sort of this graph's nodes according to their heights yields `ABCDEFGH` which is - at least for log output - highly undesirable. We want either `ABDFCEGH` or `ACEGBDFH`. # Complex heights @@ -67,47 +63,41 @@ Here is an example: Now, consider a node with the number `a.b.c` with not yet numbered children. The first child of this node will get the number `a.b.c+1`, the other `N-1` children get the numbers `a.b.c.0.0` through `a.b.c.N-2.0`. When a node has multiple parents, it gets the maximum of all numbers that would be assigned according to the rule in the previous sentence. Note that this asymmetrical: One child will get a tuple that has a size equal to that of the parent, while the other children get longer tuples. Here is an example: -{{{ - A 0----. - /|\ / \ \ - B C D 1 0.0.0 0.1.0 - | |/ \ | | / \ - | E | | 0.1.1 | - |/ \ | => | / \ | - F G | 2 0.1.2 | - | |/ | \ / - H I 3 0.1.3 - : : : : -}}} + A 0----. + /|\ / \ \ + B C D 1 0.0.0 0.1.0 + | |/ \ | | / \ + | E | | 0.1.1 | + |/ \ | => | / \ | + F G | 2 0.1.2 | + | |/ | \ / + H I 3 0.1.3 + : : : : ## Discussion This schema has the advantage of keeping linear chains of revisions together. If a revision `A` has only one child `B`, and `B` has only one parent `A`, there will be no other revision with a number that sorts in between `A` and `B`. The disadvantage is that sorting is a bit more expensive than with simple heights, because you have to compare tuples now. The tuples might become longer over time when there abandoned branches that accidentally got shorter tuples. This can't be avoided apriori. However, you can always renumber the whole graph, taking into account that very old branches will probably never be merged, and assign longer tuples to them. A good strategy is to identify a branch that likely will always be merged back (e.g. `n.v.m`) and try to always assign the shorter tuples to revisions carrying that branch cert. For the current `nvm*` graph, the longest tuples have 13 elements. That's the example with problematic log output from above, now with complex heights: -{{{ - A 0 - / \ / \ - B C 1 0.0.0 - | | | | - D E => 2 0.0.1 - | | | | - F G 3 0.0.2 - \ / \ / - H 4 -}}} -The topological sort according to the node's heights yields {{{ACEGBDFH}}}. + A 0 + / \ / \ + B C 1 0.0.0 + | | | | + D E => 2 0.0.1 + | | | | + F G 3 0.0.2 + \ / \ / + H 4 +The topological sort according to the node's heights yields `ACEGBDFH`. ## Implementation A complex height is an array of integers. If you store the integers subsequently and in big endian format, a comparison of the resulting byte sequence using memcmp() yields the correct result for the ordering described earlier. The advantage is that - once created - revision heights need not to be interpreted, but can be passed around as blobs. Moreover, you can even ask the database to perform comparisons for you: -{{{ -SELECT ... -FROM revisions -JOIN heights ON revisions.id=heights.revision -WHERE ... -ORDER BY heights.height -}}} + SELECT ... + FROM revisions + JOIN heights ON revisions.id=heights.revision + WHERE ... + ORDER BY heights.height This yields a toposorted list of revisions even for complex heights, because the database (at least SQLite) sorts the blobs using memcmp(). ## Messages on address@hidden ============================================================ --- wiki/RichardLevitte.mdwn dd9737b8d84151c6ffc30a8c32c8b64a65aa4308 +++ wiki/RichardLevitte.mdwn ab2a758cd6af68f87dac4c1b954aa0efd1e75758 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/RosterifyingPrivateBranches.mdwn 2c7862562db525da61da21cfafa4e2a2e237efd3 +++ wiki/RosterifyingPrivateBranches.mdwn ca720d8bde285c834530d884620429709b940387 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] /!\ WARNING: at least one person using these instructions has ended up with a database with the wrong contents, and accidentally ended up sending a few thousand spurious certs to the rest of his group. So be careful! The algorithm given here seems correct in principle, but it could be explained clearer; make sure you are very careful if you use it, or ask in #monotone @ irc.oftc.net for hints, until we find time to expand this page. @@ -9,21 +9,15 @@ The first step is to rosterify your priv Make sure you make a backup of your database before attempting any of these steps. The first step is to rosterify your private database. -{{{ -$ mtn db migrate --db private.mtn -$ mtn db rosterify --db private.mtn -}}} + $ mtn db migrate --db private.mtn + $ mtn db rosterify --db private.mtn Make sure the rosterify went ok and double-check the revisions in your private database and the main database making sure they have the same revision IDs (you only have to check the latest version). Next get a list of all the revisions in the main database and delete those from your private database. -{{{ -$ for RID in `mtn automate select i: --db main.mtn`; do mtn --db private.mtn db execute "DELETE FROM revision_certs WHERE id = '$RID'"; done -}}} + $ for RID in `mtn automate select i: --db main.mtn`; do mtn --db private.mtn db execute "DELETE FROM revision_certs WHERE id = '$RID'"; done Now your private database contains a rosterified version of your private branches with no conflicting rosterified certs. The next step is to fix the epochs for your private branches. To do this, get the epochs from the main database and set them in the private database. -{{{ -$ mtn --db main.mtn ls epochs -$ mtn --db private.mtn db set_epoch net.venge.monotone -(repeat for each overlapping branch) -}}} + $ mtn --db main.mtn ls epochs + $ mtn --db private.mtn db set_epoch net.venge.monotone + (repeat for each overlapping branch) The last step is to pull the rosterfied certs from the main database into your private database. ============================================================ --- wiki/RostersTodo/MarkAndMergeTests.mdwn 47431f5846feb1de1d858e3de9b2f2562ba37692 +++ wiki/RostersTodo/MarkAndMergeTests.mdwn 8f1ec9507ba518c975bfe95575f959f5c8e6b60d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Lots of super-critical code here. I want, like, 173% code coverage. This is the exact same stuff that led to months of discover-nasty-bug-worry-whether-we've-corrupted-data games the last time we rewrote our history code, and this code is all new. And critical. And complicated. And prone to fantastically subtle bugs with disproportionate effects. @@ -22,21 +22,15 @@ Each scalar has a number of different ca Each scalar has a number of different cases, described in the multi-*-merge doc (see [http://article.gmane.org/gmane.comp.version-control.revctrl/93 writeup]). These include: * No parents: -{{{ - a* -}}} + a* * One parent: -{{{ - a a - | | - a b* -}}} + a a + | | + a b* * Two parents: -{{{ - a a a a a b a b - \ / \ / \ / \ / - a b* c* a? (two cases here) -}}} + a a a a a b a b + \ / \ / \ / \ / + a b* c* a? (two cases here) Basically, we need to test each way each of these cases can arrive, for each of the scalars. This is made more complicated by the fact that they can arise in a number of ways: * No parents: ============================================================ --- wiki/RostersTodo.mdwn 7e1b6812218d5b4c4e42f6dbf2bc4e9cb707dee8 +++ wiki/RostersTodo.mdwn ea7ef1c59b83a921aa2fe48c0e2a1bc892fa4353 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] *This page is mostly out of date: rosters have been part of mainline monotone since the 0.26 release.* ============================================================ --- wiki/RunDbCheckOften.mdwn f7af58f53ee78780106d25bd9fb7ff7fda9ce9fe +++ wiki/RunDbCheckOften.mdwn 7a46c59576a7301dc2cfebf716f0e33c353c8ae1 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Monotone is careful about data integrity, but there are limits to what can be reasonably protected against in software. ============================================================ --- wiki/SelfHostingInfo.mdwn bc7b5317d5d1c5d4ddefb163bdfa6b0f57316e21 +++ wiki/SelfHostingInfo.mdwn 0bd746560d51f83fc739d41ec4b816c586a6f9ec @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #acl Known:read,write All:read @@ -32,12 +32,12 @@ mtn: successful exchange with monotone.c mtn: 86.4 M | 528 | 50445/50445 | 12557/12557 mtn: successful exchange with monotone.ca}}} - Note the key fingerprint in that output; you may wish to verify that it really is {{{3e6f5225bc2fffacbc20c9de37ff2dae1e20892e}}}. + Note the key fingerprint in that output; you may wish to verify that it really is `3e6f5225bc2fffacbc20c9de37ff2dae1e20892e`. /!\ In case monotone.ca is down, you could try one of these alternative servers that sync to each other regularly: ||**server**||**fingerprint**|| - ||monotone.mtn-host.prjek.net||{{{a52f85615cb2445989f525bf17a603250381a751}}}|| - ||204.152.190.23||{{{fee080c8906fc3a9a601587807df0a5088a3fdd8}}}|| + ||monotone.mtn-host.prjek.net||`a52f85615cb2445989f525bf17a603250381a751`|| + ||204.152.190.23||`fee080c8906fc3a9a601587807df0a5088a3fdd8`|| This is your initial pull so it will take a bit of time, as it has to transfer a few megabytes of history to you. Subsequent pulls will be much faster. When you're done pulling you can take a look at the heads of the branch you picked up. You should get something like this (though with a different head version, different author, etc.): {{{$ mtn --db=mtn.db --branch=net.venge.monotone heads ============================================================ --- wiki/SimplerIgnoreMechanism.mdwn c971fde4098e05adbe6a9578b8a14afab4105614 +++ wiki/SimplerIgnoreMechanism.mdwn 9b70cc3c5555e02181774c97ebf0ee7b3d5f3600 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] ## Status quo ============================================================ --- wiki/SummerOfCode2006.mdwn f3665aae3c146e38e1833e9acd910f8bdc7a2f70 +++ wiki/SummerOfCode2006.mdwn b1bfb84a435af276201548c8dea336ce61de7ce9 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Google Summer of Code -- 2006 ============================================================ --- wiki/SummerOfCode2007/Ideas.mdwn 44400155e32c63c4c25534627d4705befde093a1 +++ wiki/SummerOfCode2007/Ideas.mdwn c3b1629627bb2c4b53b300247844424daf136b08 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Ideas for the Google Summer Of Code 2007 ============================================================ --- wiki/SurveyQuestions.mdwn 76c3e7e63bd23b880188c1665796973fded43b94 +++ wiki/SurveyQuestions.mdwn 9823b1bd2b1a927c2498d21335df05143080f9da @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Other surveys: * Our first survey: http://article.gmane.org/gmane.comp.version-control.monotone.devel/2235 ============================================================ --- wiki/SymLinks.mdwn c6f2f9ac598df17b4faeaf5719d67e8c96be78dc +++ wiki/SymLinks.mdwn 6f35d8ff05e9abba8196f38e807ce5dff8a8f5b0 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] People would, occasionally, like to be able to put symlinks under version control. ============================================================ --- wiki/TestHarnessIssues/CleanUpTestNames.mdwn 224a575278150618ca9e4537fdd65c50eb71b790 +++ wiki/TestHarnessIssues/CleanUpTestNames.mdwn 3e1734e7d95aef7d8d001d4b118faf8675ad2b95 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Now that there is no giant list of test cases in `testsuite.lua`, we ought to go through and rename all the test cases so that they are in sensible clusters, and so they are run in a sensible order (very basic tests first). This page is for working out what the new names should be. If you edit this, please please keep it in alphabetical order by *new* name. ============================================================ --- wiki/TestHarnessIssues.mdwn cd865a57ddec6412baaee48518e46b784fa9bd15 +++ wiki/TestHarnessIssues.mdwn 05c25c6aa0ba0ea83e6aa88e69153fc7618d72b4 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The lua-based test harness is pretty nice, but it could be nicer. Here are some ways we could improve it: ============================================================ --- wiki/TestIntro.mdwn 0a446eba96abbb8271437c6e4423fa81c31f2c9e +++ wiki/TestIntro.mdwn 1ebb177653074db535d275b8dc4ea30fceb97470 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Put newbie info about lua tests here. @@ -6,12 +6,10 @@ Please write your observations about not ## How to run lua tests -One must build {{{tester}}} -{{{ -make tester # on unix -make tester.exe -}}} -NOTE if you invoke {{{make tester}}} on mingw make will try to build tester using implicit make rules and will fail miserably. That's the reason for giving .exe suffix. +One must build `tester` + make tester # on unix + make tester.exe +NOTE if you invoke `make tester` on mingw make will try to build tester using implicit make rules and will fail miserably. That's the reason for giving .exe suffix. To run the tests invoke following command: @@ -23,9 +21,9 @@ This is basic unittesting stuff. Interes This is basic unittesting stuff. Interesting functions: +|| `check( condition: boolean)` || fails when condition is not met || +|| `qgrep( pattern: string, filename: string) ` || returns true if pattern is found in given file || +|| `check( mtn(args ...), expected_return_value,catch_stdout, catch_stderr)` || idiom: invoke monotone with given args, check return status and possibly remember its standard and diagnostic output || +|| `get(filename) ` || read contents of file and return string || +|| `mkdir(name) ` || create directory || +|| `addfile(name, contents) ` || idiom for writefile(name, contents) , mtn add name || -|| {{{check( condition: boolean)}}} || fails when condition is not met || -|| {{{qgrep( pattern: string, filename: string) }}} || returns true if pattern is found in given file || -|| {{{check( mtn(args ...), expected_return_value,catch_stdout, catch_stderr)}}} || idiom: invoke monotone with given args, check return status and possibly remember its standard and diagnostic output || -|| {{{ get(filename) }}} || read contents of file and return string || -|| {{{ mkdir(name) }}} || create directory || -|| {{{ addfile(name, contents) }}} || idiom for writefile(name, contents) , mtn add name || ============================================================ --- wiki/Testimonials.mdwn ad20718e98e822c82420cab1fa2e7cffbc5f77ef +++ wiki/Testimonials.mdwn 4db5ee497000e3f789a7aa69991182db4feb1d8a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Tell us what you really think. @@ -16,7 +16,7 @@ Tell us what you really think. * In using Monotone from version 0.23 through version 0.30 I've seen an amazing increase in its quality and speed. In reading the development mailing list I am extremely impressed by the developers' thoroughness in their discussions of the algorithms behind monotone and their attention to the user experience and use cases that drive their usage of revision control systems. I'm convinced that monotone will only continue to get better and that it is a useful tool for all developers. -- [http://justin.patrin.info/ Justin Patrin] - * I believe that Monotone is the Ada of version control systems, so it is only appropriate that I use it for my Ada work. Monotone is safe, correct and powerful *by design*. It uses cryptographic keys to authenticate changes. It is written by elite programmers who, despite using C++, have the "Ada attitude": no pointers, one {{{assert()}}} every 9 lines of code, massive use of generics (templates), and not a single critical bug in 3 years. -- [http://groups.google.co.uk/group/comp.lang.ada/msg/bf2f9970828367bd Ludovic Brenta] + * I believe that Monotone is the Ada of version control systems, so it is only appropriate that I use it for my Ada work. Monotone is safe, correct and powerful *by design*. It uses cryptographic keys to authenticate changes. It is written by elite programmers who, despite using C++, have the "Ada attitude": no pointers, one `assert()` every 9 lines of code, massive use of generics (templates), and not a single critical bug in 3 years. -- [http://groups.google.co.uk/group/comp.lang.ada/msg/bf2f9970828367bd Ludovic Brenta] * I have been using Monotone from version 0.14, and I have never ceased to be amazed by the combination of stable functionality and high speed of development the team behind Monotone has been able to show off. The beauty and simplicity both in design concept and user interface, as well as the amazing (so far unmatched) helpfulness of the Monotone team ensures that I will be a Monotone fan for a long time to come. The extra bonus of distributed functionality, next generation features and damn near perfect documentation just makes me even happier :) -- [mailto:martin_at_troja_dot_ath_dot_cx Martin Kihlgren] 2007-01-30 ============================================================ --- wiki/ThomasKeller.mdwn d1df025099028c003ea447c33f10bc1e18e55a27 +++ wiki/ThomasKeller.mdwn 720db157586e31c6e37e7a2fe1d99875dbb23b1d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Frontend developer - mostly hacks on the automation interface in monotone and provides small bugfixes and enhancements for long-standing annoyances. ============================================================ --- wiki/TimeStamps.mdwn 8f01f494d6652eb13890b1e5a8600d72f4431fc6 +++ wiki/TimeStamps.mdwn be17b9be314458640aecf493723951158bbae57e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Maybe we should store, for each rev and cert, a timestamp of when it was written to the db? This would be purely local information, but it could be useful for forensics ("we know something happened, but have no idea what!"), and auditing ("crud, Debbie's laptop was stolen, has our (still trusted) server received any certs from her since then?"). ============================================================ --- wiki/TroubleShooting.mdwn dd0c558677b450638a549cebe6fe1bdeefa55590 +++ wiki/TroubleShooting.mdwn 4d2a8178e106f2cdb29181ca8995b062c0d90da5 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en @@ -16,11 +16,9 @@ Check for this using ldd This almost always turns out to be the result of mismatched C++ libraries. The common cause of this is that your mtn binary and the Boost libraries monotone uses on were built using different versions of the C++ compiler and ended up linked against different versions of libstdc++. Check for this using ldd -{{{ -ldd /path/to/mtn | grep 'stdc++' - libstdc++.so.5 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.5 (0xb7aae000) - libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0xb7d32000) -}}} + ldd /path/to/mtn | grep 'stdc++' + libstdc++.so.5 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.5 (0xb7aae000) + libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0xb7d32000) In this example, mtn had been freshly built, but Boost had not been rebuilt since a compiler upgrade. This caused mtn to be linked against libstdc++.so.6 when the Boost libraries were still linked against libstdc++.so.5. Rebuilding Boost was the solution in this case. @@ -29,85 +27,73 @@ This will happen if the remote host is r This will happen if the remote host is running an older version of monotone. This is because the specification of a branch pattern to serve was dropped from the `mtn serve` command in recent versions. This can be fixed by modifying the `get_netsync_connect_command` hook to execute the remote mtn process with '*' as the branch pattern. The following modified hook can be placed your monotonerc file (probably in _MTN/monotonerc), to resolve this issue. -{{{ -function get_netsync_connect_command(uri, args) - - local argv = nil - - if uri["scheme"] == "ssh" - and uri["host"] - and uri["path"] then - - argv = { "ssh" } - if uri["user"] then - table.insert(argv, "-l") - table.insert(argv, uri["user"]) - end - if uri["port"] then - table.insert(argv, "-p") - table.insert(argv, uri["port"]) - end - - table.insert(argv, uri["host"]) - end - - if uri["scheme"] == "file" and uri["path"] then - argv = { } - end - - if argv then - - table.insert(argv, get_mtn_command(uri["host"])) - - if args["debug"] then - table.insert(argv, "--debug") - else - table.insert(argv, "--quiet") - end - - table.insert(argv, "--db") - table.insert(argv, uri["path"]) - table.insert(argv, "serve") - table.insert(argv, "*") - table.insert(argv, "--stdio") - table.insert(argv, "--no-transport-auth") - - if args["include"] then - table.insert(argv, args["include"]) - end - - if args["exclude"] then - table.insert(argv, "--exclude") - table.insert(argv, args["exclude"]) - end - end - return argv -end -}}} + function get_netsync_connect_command(uri, args) + + local argv = nil + + if uri["scheme"] == "ssh" + and uri["host"] + and uri["path"] then + + argv = { "ssh" } + if uri["user"] then + table.insert(argv, "-l") + table.insert(argv, uri["user"]) + end + if uri["port"] then + table.insert(argv, "-p") + table.insert(argv, uri["port"]) + end + + table.insert(argv, uri["host"]) + end + + if uri["scheme"] == "file" and uri["path"] then + argv = { } + end + + if argv then + + table.insert(argv, get_mtn_command(uri["host"])) + + if args["debug"] then + table.insert(argv, "--debug") + else + table.insert(argv, "--quiet") + end + + table.insert(argv, "--db") + table.insert(argv, uri["path"]) + table.insert(argv, "serve") + table.insert(argv, "*") + table.insert(argv, "--stdio") + table.insert(argv, "--no-transport-auth") + + if args["include"] then + table.insert(argv, args["include"]) + end + + if args["exclude"] then + table.insert(argv, "--exclude") + table.insert(argv, args["exclude"]) + end + end + return argv + end ### Check Your Quoting On Windows -{{{ -mtn sync myhost.com 'mybranch' -}}} + mtn sync myhost.com 'mybranch' does not find a branch named mybranch, but -{{{ -mtn sync myhost.com "mybranch" -}}} + mtn sync myhost.com "mybranch" does. Also on Windows, glob expansion can be rather funky, e.g. -{{{ -mtn sync myhost.com '*' -}}} + mtn sync myhost.com '*' and -{{{ -mtn sync myhost.com "*" -}}} + mtn sync myhost.com "*" ...will both undergo glob expansion, resulting in a command-line which contains a list of files in the current directory. To get around this, use -{{{ -mtn sync myhost.com "{}*" -}}} + mtn sync myhost.com "{}*" ''Add an 'x' here if this helped you'': x @@ -116,22 +102,16 @@ A bug in monotone right now is that it d A bug in monotone right now is that it does a lousy job of giving feedback when your permissions are set up wrong -- usually the server will just drop your connection, instead of sending you a message explaining why. If your new server does not appear to be accepting your connections try: * checking the server log for any notes about permissions * make sure your read permission file is correct -- it is in a simple little language that looks like: -{{{ -pattern "*" -allow "address@hidden" -allow "address@hidden" -}}} + pattern "*" + allow "address@hidden" + allow "address@hidden" to allow Abe and Beth read access to all branches, or -{{{ -pattern "foo*" -allow "*" -}}} + pattern "foo*" + allow "*" to allow anonymous access to all branches whose names begin "foo". * make sure your write permission file is correct -- it is **not** the same format as the read permission file, because write permissions are per-db, while read permissions are per-branch. (This has to do with the somewhat amorphous nature of monotone branches.) A write permissions file might look like -{{{ address@hidden address@hidden -}}} + address@hidden + address@hidden ''Add an 'x' here if this helped you'': ============================================================ --- wiki/TrustDiscussion.mdwn 8d061a5131141634b11423dc036cd1312f6623ba +++ wiki/TrustDiscussion.mdwn f7609f50afa7c1f782de89d9a9ccf54374104d8d @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] We need a more systematic way to deal with trust in monotone, including delegation ("let the maintainers worry about who gets commit access, I just want to submit patches"), revocation, and such things. ============================================================ --- wiki/TrustFoundations.mdwn 5140b4eb879188c430b4a035a9da03847b071e58 +++ wiki/TrustFoundations.mdwn f5c91b8bb0fed349fd86e78e5d877b848b3bef96 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] In Monotone, all trust is handled on the basis of certificates (called certs). ============================================================ --- wiki/User:Metaeducation.mdwn 52a6f318a1d28a595b0ce4b932859253c49d76ea +++ wiki/User:Metaeducation.mdwn 3b8a931635cedf8acafed6529886654234c4ffe4 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Hello there. I was a programmer for a long time and have worked on two "distributed version control systems" in the past. I am evaluating the monotone project and perhaps will be able to contribute in interesting ways. ============================================================ --- wiki/UsingCerts.mdwn 085555165f627f23025f5cae8129fbe5311662ab +++ wiki/UsingCerts.mdwn 1946c79d5950ca510d1b14527ed2b1447f65dd2e @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Monotone stores important information about revisions in certs. This page descibes how some of the common certs are used in practice; you can also define your own CustomCerts for your own purposes. ============================================================ --- wiki/VendorBranchPattern.mdwn 05f7dfd5053b36427c582d17d8bb5354d68a2dd8 +++ wiki/VendorBranchPattern.mdwn 0016658f5d17ec1ddb630a332ef84b6ef47ffe88 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] If you are working on a project that has been partitioned, give each partition a branch. A partition could be upstream code. ============================================================ --- wiki/VersionedPolicy/Archive.mdwn d941eeed55f2d7f53ae7c8695a07b6fd8832fa78 +++ wiki/VersionedPolicy/Archive.mdwn e8c312c320ccb7da29502a0c99a4cdf5823ab7bd @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Random notes on how to version policy (fine-grained permissions, trust delegation, branch names...). @@ -90,7 +90,7 @@ http://article.gmane.org/gmane.comp.vers http://article.gmane.org/gmane.comp.version-control.monotone.devel/6917 ## Questions -Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it ({{{mtn -d DATABASE -bBRANCHNAME co --policy PDIR}}}), or simply specify something like {{{-bBRANCHNAME."policy"}}}. Could you provide links or information on the "big picture." -- ChadWalstrom +Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (`mtn -d DATABASE -bBRANCHNAME co --policy PDIR`), or simply specify something like `-bBRANCHNAME."policy"`. Could you provide links or information on the "big picture." -- ChadWalstrom *You plan on using a directory hierarchy...to describe policy...these branches are not working directories for your branches* -- yes, exactly right. *As another branch in the database?* -- yep again, probably with some fixed name, I guess? The exact UI beyond that I'm not sure -- certainly one thing to figure out as things settle down would be what sort of sugar is useful. I'd almost be tempted to have it automatically checked out to a subdirectory of _MTN/ or something, even, just to make things as low-impedence as possible? But this is just guessing, can't make sensible UI choices until much later in the process. -- NathanielSmith ============================================================ --- wiki/VersionedPolicy/Comparison.mdwn ec92935d6cf41883ceea13405adee556698529d2 +++ wiki/VersionedPolicy/Comparison.mdwn 83f55131514dd6ca2236cedc6265cf3e35871188 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Things in common between Paul's proposal and Graydon's ============================================================ --- wiki/VersionedPolicy/Graydon.mdwn d63cacc1f3c72d94de7561d5287b85e29bb525b7 +++ wiki/VersionedPolicy/Graydon.mdwn 414a99b3b45a56dfe60ea9b726d8bc35fc4139b2 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] # Current Design @@ -43,40 +43,40 @@ sub-branches, inlcuding an optional uniq A policy branch manages both the namespace and the permissions of its sub-branches, inlcuding an optional unique content branch that has the -same human-friendly name as the policy branch: for example, {{{foo.bar}}} +same human-friendly name as the policy branch: for example, `foo.bar` may name both a particular content branch 'and' contain policy -decisions that name and constrain the sub-branches {{{foo.bar.baz}}} and +decisions that name and constrain the sub-branches `foo.bar.baz` and {{{foo.bar.quux}}}. Aspects of policy accumulate "down" the tree, from the root policy -towards content trees. So a branch like {{{foo.bar.baz}}} is judged by -the policy of {{{foo}}}, plus the policy of {{{foo.bar}}}, plus the policy of +towards content trees. So a branch like `foo.bar.baz` is judged by +the policy of `foo`, plus the policy of `foo.bar`, plus the policy of {{{foo.bar.baz}}}. At the root of the policy-branch tree there is a branch that all -projects everywhere refer to as their parent, called {{{Root}}}. Users -construct their own content for the {{{Root}}} branch. Monotone makes a -branch called {{{Root}}} exist if you haven't created one. {{{Root}}} is not +projects everywhere refer to as their parent, called `Root`. Users +construct their own content for the `Root` branch. Monotone makes a +branch called `Root` exist if you haven't created one. `Root` is not associated with a particular project. Rather, users 'sign' revisions into the root branch: revisions in the root branch are policy that -bind top-level project names into the UI. You can think of the {{{Root}}} +bind top-level project names into the UI. You can think of the `Root` branch as a user's personal list of project-policy "mount points". This 'might' be shared between a couple of the user's personal machines, but the contents of a user's Root branch is generally private. -Why does monotone trust the user's key when signing policy in the {{{Root}}} +Why does monotone trust the user's key when signing policy in the `Root` policy branch? Because there is an external, non-versioned list of keys that each user keeps (typically a 1-entry list) that defines -which keys to trust for the {{{Root}}} branch. +which keys to trust for the `Root` branch. The important design point is that the decision for "which policy node represents the head of a policy branch" is made by evaluating 'certs' on that policy branch, and the validity of those certs is determined by -looking in the policy you have in the 'parent' branch. So branch {{{foo}}} -says which keys are legal for manipulating policy on branch {{{foo.bar}}} -(and its sub-branches), and {{{foo.bar}}} introduces the sub-branch +looking in the policy you have in the 'parent' branch. So branch `foo` +says which keys are legal for manipulating policy on branch `foo.bar` +(and its sub-branches), and `foo.bar` introduces the sub-branch {{{foo.bar.baz}}} more keys which are legal for manipulating policy on -branch {{{foo.bar.baz}}}. +branch `foo.bar.baz`. If there are multiple policy heads, one is chosen at random and used; if the user wants they can force the choice between heads. This is ============================================================ --- wiki/VersionedPolicy/Interface.mdwn 11ac080bbd6d4bf8a8185d74202054ed87ce989f +++ wiki/VersionedPolicy/Interface.mdwn b183b345a8914fcc038df0f832cb2e3fed378946 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This is what the results of the policy mechanism should be, and how it should interact with the rest of the world. ============================================================ --- wiki/VersionedPolicy/SPKIWontWork.mdwn 68582b766843abead050655fc766a9701eae3102 +++ wiki/VersionedPolicy/SPKIWontWork.mdwn 7a610b3680f75c5c196a68cc86729615e888b212 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] This page should probably be called "SPKIWontBeEnough", since it will probably work, just not provide quite as strong a formalism as we want (if we strip clocks from it). ============================================================ --- wiki/VersionedPolicy/WorkList.mdwn 9e72f901ac8ce1b12d301023bfc63ff1ae833dd7 +++ wiki/VersionedPolicy/WorkList.mdwn c7d3119140422ab4962e591812de3da448715b81 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] * Changes to certs * Bundle author+branch+date+changelog into single cert (or N name/value pairs?) ============================================================ --- wiki/VersionedPolicy.mdwn c63bb866a148f074effe22c8ffe841f3fd0a626d +++ wiki/VersionedPolicy.mdwn 8519266bfa44928b22734cbe8c390036c48a4bdf @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] The problem is to find a way to share policy for a branch about what revisions will be accepted in a way that balances simplicity and predictability with flexibility and power. ============================================================ --- wiki/Win32DeviceFiles.mdwn c1353e12c84d989b3287afc18bb94294ab3a4159 +++ wiki/Win32DeviceFiles.mdwn 07b3e8ad71f4b7b47e20cf928e95346613f8d52a @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-12-26,Mon&sel=19#l47 ============================================================ --- wiki/WorkspaceConflicts.mdwn d6e8b33e3bd331e1810e5a250ab9840de7a88f17 +++ wiki/WorkspaceConflicts.mdwn eb3c241c080745930c41d3ed8937809668018c11 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Using editable_working_tree for not only update but also for revert and checkout should allow us to re-use conflict detection and resolution machinery. For now this page lists some things about the different types of conflicts that can occur and how we'll deal with them. @@ -59,21 +59,19 @@ eg, for update, the full set of rosters eg, for update, the full set of rosters involved looks like this: -{{{ -B -|\ -| \ -| \ -T W - \ |\ - \ | \ - \| \ - U W+ - \ | - \ | - \| - U+ -}}} + B + |\ + | \ + | \ + T W + \ |\ + \ | \ + \| \ + U W+ + \ | + \ | + \| + U+ * B is base revision workspace was checked out from * W is the workspace revision (known-but-uncommitted content changes, rearrangements, attrs) ============================================================ --- wiki/ZeroConf.mdwn 3042e2c268d5d8b67d55b7ba857e2cccdd742956 +++ wiki/ZeroConf.mdwn fcaf391d10a4872549376bb0a519d50ea8a489b3 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] I was wondering if anyone has considered integrating the ZeroConf discovery protocol. For Apple fans this was known as "Rendezvous", now "Bonjour". Given monotone's ability to perform peer-to-peer syncing that it would be useful (as well as cool) to auto-discover servers for your database. ============================================================ --- wiki/elb.mdwn 287a6f9eb937e60a8bc62a26e566592b60c53f6c +++ wiki/elb.mdwn 968d409bec6596f7253702b87d445e576cb7b6c9 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] Ethan Blanton, a.k.a. Paco-Paco or elb on #monotone ============================================================ --- wiki/gwk.mdwn 2fe0f357a10dacf8fe81771e80cd70a88f1da04b +++ wiki/gwk.mdwn 7e2524db5b391277ff7d8fcb35d7c21662706fc3 @@ -1,4 +1,4 @@ -[[tag migration-wip]] +[[tag migration-auto]] #format wiki #language en ============================================================ --- wiki/ikiwikimigration.mdwn fb956921940e6e928b33c62ac3a48fcb3a6a41cf +++ wiki/ikiwikimigration.mdwn e231239d22777ec4b1230971beec49a9e068cc38 @@ -34,7 +34,7 @@ 3. Translate the markup: * preformatted code blocks are done with 4 more spaces (inside the current level of indentation, say when inside nested lists), - rather than with `{{{` and `}}}` + rather than with ```` and ```` * use [[ikiwiki/formatting]] to help, and add more notes here ============================================================ --- wiki/moin2mdwn.sed a743ebd62fb66765c90dcc3684302c979390052b +++ wiki/moin2mdwn.sed b1552b53e20ff73abdb132a72cfac0be4184b96b @@ -7,3 +7,7 @@ s/''([^']+)''/*\1*/g s/^= (.*) =/# \1/ s/'''([^']+)'''/**\1**/g s/''([^']+)''/*\1*/g +/^{{{ *.$/,/^}}} *.$/s/^/ / +/^ ({{{|}}}) *.$/d +/^[^{]/s/{{{ *([^}`]+) *}}}/`\1`/g +/^[^{]/s/{{{ *([^}]+) *}}}/``\1``/g ============================================================ --- wiki.mdwn 3a38cfaeef8d1a3db85142c8256f0e7705575442 +++ wiki.mdwn f034719adafcec8b4a058925e8bb91f0de12e1ea @@ -13,6 +13,10 @@ page) will be determined later. [[map pages="wiki/* and link(migration-wip)"]] +## Pages tagged as migration-auto + +[[map pages="wiki/* and link(migration-auto)"]] + ## Unmigrated moin files [[map pages="wiki/*.moin"]]