# # # delete "wiki/DaggyFixes.moin" # # delete "wiki/ZipperMerge.moin" # # rename "wiki/AttrUseCases.moin" # to "wiki/AttrUseCases.mdwn" # # rename "wiki/AutoInodeprints.moin" # to "wiki/AutoInodeprints.mdwn" # # rename "wiki/AutomateMagic.moin" # to "wiki/AutomateMagic.mdwn" # # rename "wiki/AutomateVersions.moin" # to "wiki/AutomateVersions.mdwn" # # rename "wiki/AutomateWishlist.moin" # to "wiki/AutomateWishlist.mdwn" # # rename "wiki/BasicIoFormalization.moin" # to "wiki/BasicIoFormalization.mdwn" # # rename "wiki/BestPractices.moin" # to "wiki/BestPractices.mdwn" # # rename "wiki/BranchAnalogy.moin" # to "wiki/BranchAnalogy.mdwn" # # rename "wiki/BranchNamingConventions.moin" # to "wiki/BranchNamingConventions.mdwn" # # rename "wiki/BranchRenaming.moin" # to "wiki/BranchRenaming.mdwn" # # rename "wiki/BranchStatuses.moin" # to "wiki/BranchStatuses.mdwn" # # rename "wiki/BranchUI.moin" # to "wiki/BranchUI.mdwn" # # rename "wiki/BugSquashingParty.moin" # to "wiki/BugSquashingParty.mdwn" # # rename "wiki/BuildBot.moin" # to "wiki/BuildBot.mdwn" # # rename "wiki/BuildingOnMac.moin" # to "wiki/BuildingOnMac.mdwn" # # rename "wiki/BuildingOnSolaris.moin" # to "wiki/BuildingOnSolaris.mdwn" # # rename "wiki/BuildingOnWindows/VC8.moin" # to "wiki/BuildingOnWindows/VC8.mdwn" # # rename "wiki/BuildingOnWindows/VisualC8.moin" # to "wiki/BuildingOnWindows/VisualC8.mdwn" # # rename "wiki/BuildingViaPkgsrc.moin" # to "wiki/BuildingViaPkgsrc.mdwn" # # rename "wiki/CarrotAndStick.moin" # to "wiki/CarrotAndStick.mdwn" # # rename "wiki/CaseInsensitiveFilesystems.moin" # to "wiki/CaseInsensitiveFilesystems.mdwn" # # rename "wiki/CertCleanup.moin" # to "wiki/CertCleanup.mdwn" # # rename "wiki/ChadWalstrom.moin" # to "wiki/ChadWalstrom.mdwn" # # rename "wiki/ChangeLog.moin" # to "wiki/ChangeLog.mdwn" # # rename "wiki/CherryPicking.moin" # to "wiki/CherryPicking.mdwn" # # rename "wiki/ChristofPetig.moin" # to "wiki/ChristofPetig.mdwn" # # rename "wiki/CraigLennox.moin" # to "wiki/CraigLennox.mdwn" # # rename "wiki/CreatingBranches.moin" # to "wiki/CreatingBranches.mdwn" # # rename "wiki/CvsImport.moin" # to "wiki/CvsImport.mdwn" # # rename "wiki/CvsSync.moin" # to "wiki/CvsSync.mdwn" # # rename "wiki/CvsSync3.moin" # to "wiki/CvsSync3.mdwn" # # rename "wiki/DagBasedRefinement.moin" # to "wiki/DagBasedRefinement.mdwn" # # rename "wiki/DatabaseLocking.moin" # to "wiki/DatabaseLocking.mdwn" # # rename "wiki/DeltaStorageStrategies/ShootOut.moin" # to "wiki/DeltaStorageStrategies/ShootOut.mdwn" # # rename "wiki/DeltaStorageStrategies.moin" # to "wiki/DeltaStorageStrategies.mdwn" # # rename "wiki/DerekScherger.moin" # to "wiki/DerekScherger.mdwn" # # rename "wiki/DevGroup.moin" # to "wiki/DevGroup.mdwn" # # rename "wiki/EmileSnyder.moin" # to "wiki/EmileSnyder.mdwn" # # rename "wiki/EssentialMonotone.moin" # to "wiki/EssentialMonotone.mdwn" # # rename "wiki/Feature/AccessControl.moin" # to "wiki/Feature/AccessControl.mdwn" # # rename "wiki/Feature/AtomicCommit.moin" # to "wiki/Feature/AtomicCommit.mdwn" # # rename "wiki/Feature/BuildIntegration.moin" # to "wiki/Feature/BuildIntegration.mdwn" # # rename "wiki/Feature/CVSExport.moin" # to "wiki/Feature/CVSExport.mdwn" # # rename "wiki/Feature/CVSImport.moin" # to "wiki/Feature/CVSImport.mdwn" # # rename "wiki/Feature/CommitMail.moin" # to "wiki/Feature/CommitMail.mdwn" # # rename "wiki/Feature/CompactRepository.moin" # to "wiki/Feature/CompactRepository.mdwn" # # rename "wiki/Feature/EmbeddedIDs.moin" # to "wiki/Feature/EmbeddedIDs.mdwn" # # rename "wiki/Feature/Fast.moin" # to "wiki/Feature/Fast.mdwn" # # rename "wiki/Feature/LightweightBranches.moin" # to "wiki/Feature/LightweightBranches.mdwn" # # rename "wiki/Feature/LogReview.moin" # to "wiki/Feature/LogReview.mdwn" # # rename "wiki/Feature/LogTemplates.moin" # to "wiki/Feature/LogTemplates.mdwn" # # rename "wiki/Feature/MIMEtypes.moin" # to "wiki/Feature/MIMEtypes.mdwn" # # rename "wiki/Feature/Merging.moin" # to "wiki/Feature/Merging.mdwn" # # rename "wiki/Feature/Mirroring.moin" # to "wiki/Feature/Mirroring.mdwn" # # rename "wiki/Feature/NetworkSecurity.moin" # to "wiki/Feature/NetworkSecurity.mdwn" # # rename "wiki/Feature/Obliterate.moin" # to "wiki/Feature/Obliterate.mdwn" # # rename "wiki/Feature/Offline.moin" # to "wiki/Feature/Offline.mdwn" # # rename "wiki/Feature/Portable.moin" # to "wiki/Feature/Portable.mdwn" # # rename "wiki/Feature/Rename.moin" # to "wiki/Feature/Rename.mdwn" # # rename "wiki/Feature/RobustRepository.moin" # to "wiki/Feature/RobustRepository.mdwn" # # rename "wiki/Feature/SignedRevisions.moin" # to "wiki/Feature/SignedRevisions.mdwn" # # rename "wiki/Feature/Symlinks.moin" # to "wiki/Feature/Symlinks.mdwn" # # rename "wiki/Feature/VendorBranches.moin" # to "wiki/Feature/VendorBranches.mdwn" # # rename "wiki/Feature/WebInterface.moin" # to "wiki/Feature/WebInterface.mdwn" # # rename "wiki/FileSystemIssues.moin" # to "wiki/FileSystemIssues.mdwn" # # rename "wiki/ForSide.moin" # to "wiki/ForSide.mdwn" # # rename "wiki/FutureCryptography.moin" # to "wiki/FutureCryptography.mdwn" # # rename "wiki/Glossary.moin" # to "wiki/Glossary.mdwn" # # rename "wiki/HistoryBlueSky.moin" # to "wiki/HistoryBlueSky.mdwn" # # rename "wiki/Hosting.moin" # to "wiki/Hosting.mdwn" # # rename "wiki/HugoMills.moin" # to "wiki/HugoMills.mdwn" # # rename "wiki/I18nL10n.moin" # to "wiki/I18nL10n.mdwn" # # rename "wiki/IPv6.moin" # to "wiki/IPv6.mdwn" # # rename "wiki/InterfacesFrontendsAndTools.moin" # to "wiki/InterfacesFrontendsAndTools.mdwn" # # rename "wiki/JackLloyd.moin" # to "wiki/JackLloyd.mdwn" # # rename "wiki/JustinPatrin.moin" # to "wiki/JustinPatrin.mdwn" # # rename "wiki/KeystoreFiles.moin" # to "wiki/KeystoreFiles.mdwn" # # rename "wiki/LineEndingMunging.moin" # to "wiki/LineEndingMunging.mdwn" # # rename "wiki/LocalBadContent.moin" # to "wiki/LocalBadContent.mdwn" # # rename "wiki/LocalSpellingWords.moin" # to "wiki/LocalSpellingWords.mdwn" # # rename "wiki/LogUI.moin" # to "wiki/LogUI.mdwn" # # rename "wiki/MagicSelectors.moin" # to "wiki/MagicSelectors.mdwn" # # rename "wiki/MarcelvanderBoom.moin" # to "wiki/MarcelvanderBoom.mdwn" # # rename "wiki/MarkusSchiltknecht.moin" # to "wiki/MarkusSchiltknecht.mdwn" # # rename "wiki/MattJohnston.moin" # to "wiki/MattJohnston.mdwn" # # rename "wiki/MergeViaWorkingDir.moin" # to "wiki/MergeViaWorkingDir.mdwn" # # rename "wiki/MonotoneAndCVS.moin" # to "wiki/MonotoneAndCVS.mdwn" # # rename "wiki/MonotoneOnDebian.moin" # to "wiki/MonotoneOnDebian.mdwn" # # rename "wiki/MtnSummit/2007/AsciikReview.moin" # to "wiki/MtnSummit/2007/AsciikReview.mdwn" # # rename "wiki/MtnSummit/2007/Funding.moin" # to "wiki/MtnSummit/2007/Funding.mdwn" # # rename "wiki/MtnSummit/2007/Gibberish.moin" # to "wiki/MtnSummit/2007/Gibberish.mdwn" # # rename "wiki/MtnSummit/2007/Ideas.moin" # to "wiki/MtnSummit/2007/Ideas.mdwn" # # rename "wiki/MtnSummit/2007/InterestAndDates.moin" # to "wiki/MtnSummit/2007/InterestAndDates.mdwn" # # rename "wiki/MtnSummit/2007/LogisticsNA.moin" # to "wiki/MtnSummit/2007/LogisticsNA.mdwn" # # rename "wiki/MtnSummit/2007/Notes.moin" # to "wiki/MtnSummit/2007/Notes.mdwn" # # rename "wiki/MtnSummit/2007/Rooms.moin" # to "wiki/MtnSummit/2007/Rooms.mdwn" # # rename "wiki/MtnSummit/2007/Schedule.moin" # to "wiki/MtnSummit/2007/Schedule.mdwn" # # rename "wiki/MtnSummit/2007.moin" # to "wiki/MtnSummit/2007.mdwn" # # rename "wiki/MtnSummit/2008/Branches.moin" # to "wiki/MtnSummit/2008/Branches.mdwn" # # rename "wiki/MtnSummitWishes.moin" # to "wiki/MtnSummitWishes.mdwn" # # rename "wiki/MultiParentWorkspaceFallout.moin" # to "wiki/MultiParentWorkspaceFallout.mdwn" # # rename "wiki/NonMergeConflicts.moin" # to "wiki/NonMergeConflicts.mdwn" # # rename "wiki/NotesOnTestingChangesetify.moin" # to "wiki/NotesOnTestingChangesetify.mdwn" # # rename "wiki/OldTestHarnessIssues.moin" # to "wiki/OldTestHarnessIssues.mdwn" # # rename "wiki/OneBranchPerDbForServe.moin" # to "wiki/OneBranchPerDbForServe.mdwn" # # rename "wiki/PartialPull.moin" # to "wiki/PartialPull.mdwn" # # rename "wiki/PaulCrowley.moin" # to "wiki/PaulCrowley.mdwn" # # rename "wiki/People.moin" # to "wiki/People.mdwn" # # rename "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.moin" # to "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn" # # rename "wiki/PerformanceWork.moin" # to "wiki/PerformanceWork.mdwn" # # rename "wiki/PieceCache.moin" # to "wiki/PieceCache.mdwn" # # rename "wiki/ProjectsUsingMonotone.moin" # to "wiki/ProjectsUsingMonotone.mdwn" # # rename "wiki/QuickieTasks.moin" # to "wiki/QuickieTasks.mdwn" # # rename "wiki/RelativePathnames.moin" # to "wiki/RelativePathnames.mdwn" # # rename "wiki/ReleaseBranchPattern.moin" # to "wiki/ReleaseBranchPattern.mdwn" # # rename "wiki/RevertUI.moin" # to "wiki/RevertUI.mdwn" # # rename "wiki/RevisionNumbering.moin" # to "wiki/RevisionNumbering.mdwn" # # rename "wiki/RichardLevitte.moin" # to "wiki/RichardLevitte.mdwn" # # rename "wiki/RosterifyingPrivateBranches.moin" # to "wiki/RosterifyingPrivateBranches.mdwn" # # rename "wiki/RostersTodo/MarkAndMergeTests.moin" # to "wiki/RostersTodo/MarkAndMergeTests.mdwn" # # rename "wiki/RostersTodo.moin" # to "wiki/RostersTodo.mdwn" # # rename "wiki/RunDbCheckOften.moin" # to "wiki/RunDbCheckOften.mdwn" # # rename "wiki/SelfHostingInfo.moin" # to "wiki/SelfHostingInfo.mdwn" # # rename "wiki/SimplerIgnoreMechanism.moin" # to "wiki/SimplerIgnoreMechanism.mdwn" # # rename "wiki/SummerOfCode2006.moin" # to "wiki/SummerOfCode2006.mdwn" # # rename "wiki/SummerOfCode2007/Ideas.moin" # to "wiki/SummerOfCode2007/Ideas.mdwn" # # rename "wiki/SurveyQuestions.moin" # to "wiki/SurveyQuestions.mdwn" # # rename "wiki/SymLinks.moin" # to "wiki/SymLinks.mdwn" # # rename "wiki/TestHarnessIssues/CleanUpTestNames.moin" # to "wiki/TestHarnessIssues/CleanUpTestNames.mdwn" # # rename "wiki/TestHarnessIssues.moin" # to "wiki/TestHarnessIssues.mdwn" # # rename "wiki/TestIntro.moin" # to "wiki/TestIntro.mdwn" # # rename "wiki/Testimonials.moin" # to "wiki/Testimonials.mdwn" # # rename "wiki/ThomasKeller.moin" # to "wiki/ThomasKeller.mdwn" # # rename "wiki/TimeStamps.moin" # to "wiki/TimeStamps.mdwn" # # rename "wiki/TroubleShooting.moin" # to "wiki/TroubleShooting.mdwn" # # rename "wiki/TrustDiscussion.moin" # to "wiki/TrustDiscussion.mdwn" # # rename "wiki/TrustFoundations.moin" # to "wiki/TrustFoundations.mdwn" # # rename "wiki/User:Metaeducation.moin" # to "wiki/User:Metaeducation.mdwn" # # rename "wiki/UsingCerts.moin" # to "wiki/UsingCerts.mdwn" # # rename "wiki/VendorBranchPattern.moin" # to "wiki/VendorBranchPattern.mdwn" # # rename "wiki/VersionedPolicy/Archive.moin" # to "wiki/VersionedPolicy/Archive.mdwn" # # rename "wiki/VersionedPolicy/Comparison.moin" # to "wiki/VersionedPolicy/Comparison.mdwn" # # rename "wiki/VersionedPolicy/Graydon.moin" # to "wiki/VersionedPolicy/Graydon.mdwn" # # rename "wiki/VersionedPolicy/Interface.moin" # to "wiki/VersionedPolicy/Interface.mdwn" # # rename "wiki/VersionedPolicy/SPKIWontWork.moin" # to "wiki/VersionedPolicy/SPKIWontWork.mdwn" # # rename "wiki/VersionedPolicy/WorkList.moin" # to "wiki/VersionedPolicy/WorkList.mdwn" # # rename "wiki/VersionedPolicy.moin" # to "wiki/VersionedPolicy.mdwn" # # rename "wiki/Win32DeviceFiles.moin" # to "wiki/Win32DeviceFiles.mdwn" # # rename "wiki/WorkspaceConflicts.moin" # to "wiki/WorkspaceConflicts.mdwn" # # rename "wiki/ZeroConf.moin" # to "wiki/ZeroConf.mdwn" # # rename "wiki/elb.moin" # to "wiki/elb.mdwn" # # rename "wiki/gwk.moin" # to "wiki/gwk.mdwn" # # patch "wiki/AttrUseCases.mdwn" # from [2d4a515f1570b9b0742bc0405a481340175fba3f] # to [28ad729b1a091fd2bfcbf8b6aecf33bcbc19a010] # # patch "wiki/AutoInodeprints.mdwn" # from [e08af3462cb1553add68a59e456e6ba9c3778b88] # to [34e2067b3a72045144df0d3519db3b23ac0851cc] # # patch "wiki/AutomateMagic.mdwn" # from [2724845adddeba413546d3b0de606e72b4edfe46] # to [9906e2fadd6fe925a4d0bf5ea413ea74ec491cc8] # # patch "wiki/AutomateVersions.mdwn" # from [8fe4aed794a15346037232c734d1b406017aa7d6] # to [4b8e9e7df7890ae77715d6f6f359eb32289906c3] # # patch "wiki/AutomateWishlist.mdwn" # from [f3bb3bdae39ddb18e4ede0eeaeddb6cea8abdb84] # to [9e60a86c160b796410ad0dcbcb512bfe294bc090] # # patch "wiki/BasicIoFormalization.mdwn" # from [c0f2b9a879db4c1cb480a5cc71e2d75bd02c447c] # to [1a03eedc6b863debf07faf3103201420327e6d5c] # # patch "wiki/BestPractices.mdwn" # from [9e4acb167835df9bbc9c7b3c6553c0b43407d6b9] # to [2e172c2d23098a8623f44ea8a1a67db550a695ab] # # patch "wiki/BranchAnalogy.mdwn" # from [69abef4c1813f7a5818525da77e1d9fd086062e2] # to [cc8a4bfd82b69aa080a21a7241208c6141307cda] # # patch "wiki/BranchNamingConventions.mdwn" # from [ca8b98456a645a38e80fb0e3d262ae21f3c7a391] # to [195f41472ac53cb719e713fc95140febc5c1ccdd] # # patch "wiki/BranchRenaming.mdwn" # from [a0d5788f425f769f52ee6e2beb1ffa1fc6c965cd] # to [b8db5634de32b04faa1fbc0a90b3a7d0d6675e0b] # # patch "wiki/BranchStatuses.mdwn" # from [812a0cacf85649e9048dd5565cc999419caeba14] # to [3a294c70d9cc293ad71216673176a8b8e46bb793] # # patch "wiki/BranchUI.mdwn" # from [5897ef1838f3d13d94953899703b12e59a1c225e] # to [880da7619aff3fb0e3683611f80cb784502774c6] # # patch "wiki/BugSquashingParty.mdwn" # from [2e9e6b95e37d59ece66e2e74822907d7717a2d2a] # to [9fc823e6825667b2d40881fe08c01d3330cd6b67] # # patch "wiki/BuildBot.mdwn" # from [7c24a658a87cec3360d3091a91c5a834a9cbbb3f] # to [100b7b92675080b560373def21c47a846a80039d] # # patch "wiki/BuildingOnMac.mdwn" # from [8e18c22e92eb6a0b0d2bad3a4ea7065821787771] # to [cbec17ebfa915d864e1b1c79d830e760c4e795c1] # # patch "wiki/BuildingOnSolaris.mdwn" # from [a3534a897e8126fde927e9c9966da24a9a3bf574] # to [c8bfbc121048baa94dc5d7a6f808fe9a30d533f3] # # patch "wiki/BuildingOnWindows/VC8.mdwn" # from [cc2cfccb331742343b64e1836ef6dbd3d1436139] # to [bdd4f56d523bc78d3e5a377140ab3aaf7d629f6a] # # patch "wiki/BuildingOnWindows/VisualC8.mdwn" # from [d598f53c08ce10e7405e13f34a375decb133f778] # to [bdbfab37f2165a12c375a5aa4dce84077e6a43cf] # # patch "wiki/BuildingViaPkgsrc.mdwn" # from [3b33859830e445df2fc2095c4b7ae2affa06f134] # to [d2a5a7207282a2b62df155cfe6916250faa52b47] # # patch "wiki/CarrotAndStick.mdwn" # from [cdde4c203d05d2a72f52e4e3b86a5991436cd507] # to [dd68135ee164e40b236eabafd71a9d4b9702d511] # # patch "wiki/CaseInsensitiveFilesystems.mdwn" # from [ed3bdd8d05b0625558c8a29e0d72abac456fc17a] # to [399c68b79dd983fa10befc1f14d63b6e9cd67696] # # patch "wiki/CertCleanup.mdwn" # from [c47fd639b8465493a96065fe6dc36e12ea7086ef] # to [c719e5fe06aab7d1b9c58e1aee6528573f6b69c1] # # patch "wiki/ChadWalstrom.mdwn" # from [5ae7f609607231dd8a8429ebdafd94a11448e435] # to [d5766ac6ec33842ae18443b6cc37ae5dae8b093a] # # patch "wiki/ChangeLog.mdwn" # from [7ae6cc3b924c08cbe32cd85f74aec76697ca6a29] # to [a41c6e2186c7baf99020cb9ec77d639d1f573b1c] # # patch "wiki/CherryPicking.mdwn" # from [1d4f82bab5129c0293f8ceee7b6c18f0cfea9a16] # to [02db5fd6b04b151328347871f745a57dd7259713] # # patch "wiki/ChristofPetig.mdwn" # from [307ebcf0bf77c77c1ab7fc4041ac9f44fd6ffe6e] # to [68bfdf45f079aca4a14eff4e883a9448b770b367] # # patch "wiki/CraigLennox.mdwn" # from [b3b5cd92610b50b0c40a750654f5956964cf6363] # to [0d58a96602111ae00ab7dae7fa6c4b1c68ca8ffd] # # patch "wiki/CreatingBranches.mdwn" # from [4604514e5fbbbac792bed9166495397a6e819735] # to [b1f7c9b4e653c3dfda3fbf2e83ac428f8792f0f5] # # patch "wiki/CvsImport.mdwn" # from [3d5dcd92ea387b33e0a7746faf25937599da0a70] # to [4ce058f21673400073d7007b050cff953342aa90] # # patch "wiki/CvsSync.mdwn" # from [3bc2bc0b23d7a4d9d92bd1a5ed82bf3fbf9dab0f] # to [92804911fad04a6f54fa3c3eafd8e46ecdd729a2] # # patch "wiki/CvsSync3.mdwn" # from [1328aa4f58d623e4d2e30e55d543ca7d4de8d980] # to [73333f0252e0c030af2a6d7ac44108c199989e3b] # # patch "wiki/DagBasedRefinement.mdwn" # from [37da0c8d23a1a51c371a90c8e9482baf67c8edd7] # to [12853aa0f5827d4b57db17d7c60130296f808027] # # patch "wiki/DatabaseLocking.mdwn" # from [10a3ab523a33216b9943e9113308a30bbbc364be] # to [4de6bde9707ce9f70e2961118222959bb01c1af4] # # patch "wiki/DeltaStorageStrategies/ShootOut.mdwn" # from [dd0b0d51efc27bc72c6825e27875ef28f83428ad] # to [6f52fe1f30481dce1482e63225e8ea2066b9cee5] # # patch "wiki/DeltaStorageStrategies.mdwn" # from [bd9cbd626092970d68005364aff90008380ecac4] # to [d798bb1c080834f4d9f15a5f5a30d4f9f077769d] # # patch "wiki/DerekScherger.mdwn" # from [f22501976e4e878a786edf6221944d2527a69234] # to [7c23559593fcc0b960f0a6af6ce6a4f0e7371b5a] # # patch "wiki/DevGroup.mdwn" # from [3e26e8355833e3b04744c6b893e6c98dcee3edec] # to [0aa37b3c943fd9489bae7d72a5e7b5364076f178] # # patch "wiki/EmileSnyder.mdwn" # from [2e482b3b818313e543baa791c73e927930004ba7] # to [aa9316ddc5d5b96ce1bb42a4b1fa97da566938d5] # # patch "wiki/EssentialMonotone.mdwn" # from [f1ecd084a3c201cb3ff9fdc9208b24bf5b1c709a] # to [faf145c09aed47b366d630a5c00f4e3b016322fd] # # patch "wiki/Feature/AccessControl.mdwn" # from [8f7c9fe5d34752bad05c8c3007c49f0a8fc20fda] # to [602447a5122d82a14117f80dfdf3a1e89f5551cb] # # patch "wiki/Feature/AtomicCommit.mdwn" # from [469132dcb1d0fb699a76631859bc0ea9e6ceb6ae] # to [25ad516ced4862d86105b75d4ec61c49effc9a19] # # patch "wiki/Feature/BuildIntegration.mdwn" # from [2dd9641c27e5a6c155f65eb2a07df3fda444f892] # to [be9278519c0ab85a38f369d6870d40fa34b967f6] # # patch "wiki/Feature/CVSExport.mdwn" # from [ef43adf7b60c45efe9bebafd0fd9cc69f4d58841] # to [df4ff494269e75202d77a795b5e2e68342bafc6a] # # patch "wiki/Feature/CVSImport.mdwn" # from [cab653a8e28ccc3be9552b893ead580eeb91a68b] # to [5c6300c9fe93bb2590b185e4444478c09a1c7a80] # # patch "wiki/Feature/CommitMail.mdwn" # from [fb5b17ceb5b3bf9a695dda9d061588219009da12] # to [67ec4dcec228783fc0eb8b18a14be89f7c3c1c38] # # patch "wiki/Feature/CompactRepository.mdwn" # from [a7eb23003f1e60e43667394887705a52fb89bc18] # to [98b623ce12da9e23ac4543f5baaedf73a76706e9] # # patch "wiki/Feature/EmbeddedIDs.mdwn" # from [5e31f7b8fe2e8e5981fd37021776c4f3f7ce6589] # to [b1dd19db90df9c62f18d6a979fd84e4a82f825f0] # # patch "wiki/Feature/Fast.mdwn" # from [f1f75891942a3cb75dce7f4e56d86e505bc5be52] # to [30efd1cd6f42c4b0580efc513d21463a04b0ae79] # # patch "wiki/Feature/LightweightBranches.mdwn" # from [aad2b4d0e1090373a9a1ff2625a4ab051ca08f97] # to [d8ec536deeb0f29e7f83d8ce4791fe28ca0f0b78] # # patch "wiki/Feature/LogReview.mdwn" # from [af13f2028f5066c6c465554cd4aca95cebdfc685] # to [47bdd8f9d66eafa14c1e8bdb822d7e3ac89369f9] # # patch "wiki/Feature/LogTemplates.mdwn" # from [6b95d3adfff23d25a6dbae1febe95f054f80427b] # to [ff0d39741e3af68270d6f66c6dbe0020eb6d7ffc] # # patch "wiki/Feature/MIMEtypes.mdwn" # from [cbefa97b30b877d7567618f7f1bc4b81ac464dee] # to [5eac1573212dcdd39fa83463c58ef13b3a347566] # # patch "wiki/Feature/Merging.mdwn" # from [8c6ec6653a5f36e274b737147a00ee451e454c69] # to [16325f0f42a0b0e20fe053f9dfefc3cdb84ae8e8] # # patch "wiki/Feature/Mirroring.mdwn" # from [baf14ce474fc0b2a7e726b4a16b22c90836ec5fa] # to [e9fec1d6599111682bca5a82346d9957c16719fd] # # patch "wiki/Feature/NetworkSecurity.mdwn" # from [a6108cdc69b1566413971c22fefd6ad070b722ae] # to [d2d1cb04c0b62e3594ee5b8173c341f49f05eba9] # # patch "wiki/Feature/Obliterate.mdwn" # from [07da7a6da68dddc91f5a1be4c91699dfbaeb00f4] # to [94388e7338b7d632fa402748e96105bbeaff001d] # # patch "wiki/Feature/Offline.mdwn" # from [e1fbc090b60dd2e43fc9871ef70d7c230662445c] # to [cf75aa0a5f61a7f29a62f527f5a0edf0b5f65093] # # patch "wiki/Feature/Portable.mdwn" # from [58dc1094939cdd44ebb9fedc8c5d9fbb04458399] # to [8e869a5838741208c3ab03e3eacdc503f3113ae6] # # patch "wiki/Feature/Rename.mdwn" # from [2c29e9571dc1e97d4794a9539a1d142ab33c0834] # to [6c7fd056de73915f8df7438bfcdab69cf6ceee06] # # patch "wiki/Feature/RobustRepository.mdwn" # from [a8f91a82b8581a5310e3e437d19a0b131afd9b36] # to [95cf48aeded395db8848c15993dcf85cafbd0f46] # # patch "wiki/Feature/SignedRevisions.mdwn" # from [a4a5100a01dd26c8aa483a89a7fbfdb886eac4c3] # to [39be6532825e0c03545be5263107e5c717ba10f0] # # patch "wiki/Feature/Symlinks.mdwn" # from [2a3964d71fbc071f92452d34365946fd56283c88] # to [eff0776f2e133f6b6869957af5d901cea120f2b3] # # patch "wiki/Feature/Template.mdwn" # from [08af1f5d6ceaec78bd8456ae9b133ddd7b39dd78] # to [4de54aad3a1774b166e5ac7776cf060ee70531a6] # # patch "wiki/Feature/VendorBranches.mdwn" # from [f03506ca59fbef2f3df1f0fed561f86dd26fbe4a] # to [784aad745e2bfce39b6786e3f8b55fa5c8332787] # # patch "wiki/Feature/WebInterface.mdwn" # from [9157dd1e6ad73fddb4056fe1dc4e1af212c128fb] # to [ea021a1a917c9a8e8b59fded3a64b796e5acd308] # # patch "wiki/FileSystemIssues.mdwn" # from [8d73f3572a576b94a792214523e2ae55fd329fa9] # to [f9d34b769014225c5eadde10398f3f54a2b7fd9c] # # patch "wiki/ForSide.mdwn" # from [e919705b36da5a0e07b8879015d678ae520188f2] # to [49224ef964b59238b37bfd0d54e05684efd0356a] # # patch "wiki/FutureCryptography.mdwn" # from [c98562ff69dfb2f85d5f1bce968b570253e1262e] # to [1357ffb4527c1b5530654216fc0a533811a83c92] # # patch "wiki/Glossary.mdwn" # from [2a6b1a782845668a8250f7d73e7871544d1b7fba] # to [8169c5e85885d58a63b8a72075f53058d9994766] # # patch "wiki/HistoryBlueSky.mdwn" # from [8755486b8b434b2ef10e8267edcf4b216f226b91] # to [3a5e4b3e848dde314aead126826edb1ea5ac0946] # # patch "wiki/Hosting.mdwn" # from [f13962875f0a802cf96b0190b44fba8db85f78d0] # to [ab94b4fbf8ced47002785e3ab1cca6c0af890454] # # patch "wiki/HugoMills.mdwn" # from [505ee089bf7588807478d05b5e3daea0b28ceab4] # to [8b3526ec529983a4ea155558039e70b7fd34807e] # # patch "wiki/I18nL10n.mdwn" # from [68d2b64f1651c8e1036990aecaaf2b3fc361dcd1] # to [fcf0b74f76b8f4650f020908d54ad1a442400498] # # patch "wiki/IPv6.mdwn" # from [5c8384ba7aecb04feff53eb8ea9791b14bfadd61] # to [48a6666b21c8508128dc100665415a0d50bc1e59] # # patch "wiki/InterfacesFrontendsAndTools.mdwn" # from [9d842ffbb7c7c1a76eba9a74436614bc7fb392fc] # to [b65d58e509145238f09d29dc6a4e13b54e7ef2f4] # # patch "wiki/JackLloyd.mdwn" # from [871bb9517356b15024d2d785a7cb2994d87cb9a2] # to [9654fecf50faebb942c1011b23edc95ae9d858a6] # # patch "wiki/JustinPatrin.mdwn" # from [fc157c5c6a1ddddcdf5b3d116d1fa4ab6855dcf8] # to [5bdcd4e7827982a4e5fd5d2eabb8b586239cc922] # # patch "wiki/KeystoreFiles.mdwn" # from [9ca54de5971395feff06791195b07f3d82749565] # to [c0d87637f7942b10723c16d4faa1abfb072a6b54] # # patch "wiki/LineEndingMunging.mdwn" # from [227520a6a479c07721cd8753ada4a2a806ae7c58] # to [ec36aadccee4809958f37b1fd85c90c7dddade4d] # # patch "wiki/LocalBadContent.mdwn" # from [27f2a5b0e0af8f560a09c4f2efa863a8e9c8c821] # to [6f76d0887b4acdb08b596b78d5aae5fbc38f93f0] # # patch "wiki/LocalSpellingWords.mdwn" # from [52cd2b7dc55f492820f6f6357902327a221550ec] # to [c33eefbf5615908da497b48b5397c500f698e7d2] # # patch "wiki/LogUI.mdwn" # from [b8a27de826511801a77008d31d9e93ec2d9bb1ae] # to [d9bc2405923542fb7aead5e99d3dce94920f0c51] # # patch "wiki/MagicSelectors.mdwn" # from [1654cc137b0c52beec758f8cde22a6ccd3f2c594] # to [5903cb1b9ac1d4ca7fa4c6aaeace4c297e08a50e] # # patch "wiki/MarcelvanderBoom.mdwn" # from [09445b210958d54cefd5e0d8b2b7b865acbed17c] # to [63df608c4a0b952d19c7773593839904833c8891] # # patch "wiki/MarkusSchiltknecht.mdwn" # from [0ea0e61d51fbf2a64ba3c7c3def85883a906c7fd] # to [f31820b08fec94a20c7488ae7e111f013d491a7e] # # patch "wiki/MattJohnston.mdwn" # from [3f34326ea5c2e30679c576cca11ee94c90618a22] # to [bcb146694deff01d56d3879b66b7b2bccac72e64] # # patch "wiki/MergeViaWorkingDir.mdwn" # from [f2ded928aaad1eaee10c9ca1177b6ccc913b9210] # to [e514b5c7f268cf67c004f9303d035779014a8032] # # patch "wiki/MonotoneAndCVS.mdwn" # from [ce31a95fc059b739d1b6959a7ab8636a1da77924] # to [cad35e67ad8d80db34b1b091a01d7d093aa92179] # # patch "wiki/MonotoneOnDebian.mdwn" # from [74cade89db734e6c06635b5d20515b2f98061797] # to [0ac72fcc707cac862c04cef732b080ee54eba3f8] # # patch "wiki/MtnSummit/2007/AsciikReview.mdwn" # from [42448bd3402ac683fa617e2c93ca580d52f6f984] # to [b53c26b9b646216fb1cce573c9fea3d8648eed22] # # patch "wiki/MtnSummit/2007/Funding.mdwn" # from [b23c08536eb2b6d7b9a4510dcc45ba935b0296ac] # to [e9d1a4c25cf2417ba32e2e2fa244bc501b601f16] # # patch "wiki/MtnSummit/2007/Gibberish.mdwn" # from [a183b29fa1c64941b9299bd95cee3c5905ae12f7] # to [26238ad7803129af272a0a085cadab948b9164e0] # # patch "wiki/MtnSummit/2007/Ideas.mdwn" # from [c2df25fb4e7f294e5938c667e096dfb68e9a0326] # to [06e80157712ceef45bd1e3f8d70e502386f8bb95] # # patch "wiki/MtnSummit/2007/InterestAndDates.mdwn" # from [455a17ba1e9c10efbaeaadf82bcfc59fd794ed84] # to [13ed055222d9e31afaa81d9ec3fae360b082bb7e] # # patch "wiki/MtnSummit/2007/LogisticsNA.mdwn" # from [d8ed5b88b511e3bffaf431f642ae59cf1e733c11] # to [795773c41d1565600c9df1fc74571d8e3592cd32] # # patch "wiki/MtnSummit/2007/Notes.mdwn" # from [9d01d9c867bb058636ed3c62fd2a435cecfa52e8] # to [40c33a59e74d92b7ae791bc409aa2685ceeb42a4] # # patch "wiki/MtnSummit/2007/Rooms.mdwn" # from [b359314b3b5faed165eb2c1dfbafdf67a90faf60] # to [33c00fccf312d672d9c9fb44dfc81f257390fba6] # # patch "wiki/MtnSummit/2007/Schedule.mdwn" # from [bbb2538d1ef832e72016a1c1d5927019744fca2b] # to [cbbb9e357a270bf8e0e2e1d89524aa37daaba4e9] # # patch "wiki/MtnSummit/2007.mdwn" # from [6fb21628f57f8677432168c60a9b4e157acd7788] # to [f1044e55b7e35a0462c84a2305cf3fea1066fb12] # # patch "wiki/MtnSummit/2008/Branches.mdwn" # from [31033a89afc9276ba317e955e29b8054ffd1e09c] # to [4624d81fad4a17d69424573f0263c9ee561a111b] # # patch "wiki/MtnSummitWishes.mdwn" # from [3dd886fca22e33368fd892d8f41ed9794f275767] # to [6091a916665165d609749b049a469e4aea45a01d] # # patch "wiki/MultiParentWorkspaceFallout.mdwn" # from [dc38983f7b1169df55a274e92c3d58df71402b8e] # to [b6c941ff593277e86d44fb76704882196cdaabd2] # # patch "wiki/NonMergeConflicts.mdwn" # from [97d3215c1e4f1647494de48f2a8d70d52208afac] # to [236af559f86750d19177f0caca3304bfae6ca5ff] # # patch "wiki/NotesOnTestingChangesetify.mdwn" # from [adcc28128e8232940ea82ff46f7e7b7263aaaa38] # to [3d921d92e8493522c57302360e9154b766ac4ee0] # # patch "wiki/OldTestHarnessIssues.mdwn" # from [5e4daf36b863d61e5c10c8deec5e57e55d93db0f] # to [ae22459256e7946bf5b746c6f5eba6c8fa0ea748] # # patch "wiki/OneBranchPerDbForServe.mdwn" # from [51fb4788c4638f5e5b3e721501075c82dce8f7e0] # to [1a067c2618da87eee77e03d0b89446bd6cb45ccc] # # patch "wiki/PartialPull.mdwn" # from [1a55554c7ba633cc3220ef20a9d669df2b301ce0] # to [f88802944b7ca0efc5be21471a92712e74f1a81e] # # patch "wiki/PaulCrowley.mdwn" # from [022cce85a8f46c7d2d4d403280b4226dc4a0b536] # to [0946669a557a94542bb3b3e599d10620ac56d707] # # patch "wiki/People.mdwn" # from [8fe745665c2d9e04cef7b4756c9af4bd284de7da] # to [6c9ec129ad4cf8e304b07e123668899e685101eb] # # patch "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn" # from [848a85c65c1c82f2ae2fb5b772d1841d0c2519bd] # to [43f9b4893ad690d7ffe613a73504241af1a01906] # # patch "wiki/PerformanceWork.mdwn" # from [5c7c310a1718a5000d49a32ee0823cc299401e7a] # to [7734b29157885158904bdacc0e9651a5f3d97736] # # patch "wiki/PieceCache.mdwn" # from [e490d32fe5dbb194c58f839aa07fa64cf54eb5a4] # to [ba54ba6fc2223670fce9e77761b5b00fd7f71f6c] # # patch "wiki/ProjectsUsingMonotone.mdwn" # from [cc801e316277baa6308dc224a9a03efa82de21e7] # to [acdda58a620edaa6fe2f74aa6cee4e32f3b612ea] # # patch "wiki/QuickieTasks.mdwn" # from [16bd674a6e384f1de8b6a1d006609799e65a43de] # to [61c008a59f664e98a3a8d533fc5f1db70f4a7683] # # patch "wiki/RelativePathnames.mdwn" # from [c1828742bdd9c07f669d763ce2d3498597dae3ba] # to [692ce2f3610ebf2be4dce521dd9d0a99da937811] # # patch "wiki/ReleaseBranchPattern.mdwn" # from [eec7c8fc242845ff415ff2fff16df4821c6cfd9f] # to [7da38dacfada27acb510147207fefc0b0c30979c] # # patch "wiki/RevertUI.mdwn" # from [9bb3c91366b09d2626f26e835ac17c37d6632b0e] # to [43e2d1517696a780ae13fac22f9d83be1e9aa8ff] # # patch "wiki/RevisionNumbering.mdwn" # from [04be28a189d3b53fe456809e29038c2bf4580c0f] # to [f7700c3a50756659f82c390f36735b53322957cc] # # patch "wiki/RichardLevitte.mdwn" # from [338c6c65b6b6a87a461e13937af5dfff343ae1b8] # to [dd9737b8d84151c6ffc30a8c32c8b64a65aa4308] # # patch "wiki/RosterifyingPrivateBranches.mdwn" # from [a7ca9db78359567b2b21c45f27e716c884696558] # to [2c7862562db525da61da21cfafa4e2a2e237efd3] # # patch "wiki/RostersTodo/MarkAndMergeTests.mdwn" # from [41c378f4e9e463f206c7c7c686806dc77234f7d0] # to [47431f5846feb1de1d858e3de9b2f2562ba37692] # # patch "wiki/RostersTodo.mdwn" # from [48f735021a5ddfb160cfa8a8cd0b14d410ba4965] # to [7e1b6812218d5b4c4e42f6dbf2bc4e9cb707dee8] # # patch "wiki/RunDbCheckOften.mdwn" # from [ce106627aa964ce149d6ba8624ea4cc0a1ea5fc8] # to [f7af58f53ee78780106d25bd9fb7ff7fda9ce9fe] # # patch "wiki/SelfHostingInfo.mdwn" # from [f44b0f7324aa4048756217c3f8168343fdf25be1] # to [bc7b5317d5d1c5d4ddefb163bdfa6b0f57316e21] # # patch "wiki/SimplerIgnoreMechanism.mdwn" # from [c8ff6bdba6b82ea9b7104205116bb65828eaae51] # to [c971fde4098e05adbe6a9578b8a14afab4105614] # # patch "wiki/SummerOfCode2006.mdwn" # from [7a8e7def59200c3fd38e77b6bb54303b1adb703b] # to [f3665aae3c146e38e1833e9acd910f8bdc7a2f70] # # patch "wiki/SummerOfCode2007/Ideas.mdwn" # from [4164eacc1d6622649e8490e4737ddcb78f3447dd] # to [44400155e32c63c4c25534627d4705befde093a1] # # patch "wiki/SurveyQuestions.mdwn" # from [ce00608fe5316b3c974ea16799c447e436d206bb] # to [76c3e7e63bd23b880188c1665796973fded43b94] # # patch "wiki/SymLinks.mdwn" # from [ae364b3afb663daead6e99719c80de138351d502] # to [c6f2f9ac598df17b4faeaf5719d67e8c96be78dc] # # patch "wiki/TestHarnessIssues/CleanUpTestNames.mdwn" # from [7f95da9e46a9cbdb7a64c47df6d947667d1f933d] # to [224a575278150618ca9e4537fdd65c50eb71b790] # # patch "wiki/TestHarnessIssues.mdwn" # from [a1322d09445f4fca5b58416fb8514a28d1b49f7d] # to [cd865a57ddec6412baaee48518e46b784fa9bd15] # # patch "wiki/TestIntro.mdwn" # from [231b82e0722a708e2d2fa776becca84efa84d623] # to [0a446eba96abbb8271437c6e4423fa81c31f2c9e] # # patch "wiki/Testimonials.mdwn" # from [b8eda92829a0d2d19275abbd3010977819f100a1] # to [ad20718e98e822c82420cab1fa2e7cffbc5f77ef] # # patch "wiki/ThomasKeller.mdwn" # from [282b6ad99a0fb8674ff1db1101ce4a533be79ae9] # to [d1df025099028c003ea447c33f10bc1e18e55a27] # # patch "wiki/TimeStamps.mdwn" # from [ea646c9ac0cc113736513bd15e089ff2c812ac09] # to [8f01f494d6652eb13890b1e5a8600d72f4431fc6] # # patch "wiki/TroubleShooting.mdwn" # from [65743a7cca512f11264f007606f07d2391d4885e] # to [dd0c558677b450638a549cebe6fe1bdeefa55590] # # patch "wiki/TrustDiscussion.mdwn" # from [918d6d812def7ca783883a45477a4ce04dc367cc] # to [8d061a5131141634b11423dc036cd1312f6623ba] # # patch "wiki/TrustFoundations.mdwn" # from [e073a5e7c41b6da60084dacf8a1dabe6715b402b] # to [5140b4eb879188c430b4a035a9da03847b071e58] # # patch "wiki/User:Metaeducation.mdwn" # from [dbbb2c70181ac97dfaf0967a5d1ee01a226332d8] # to [52a6f318a1d28a595b0ce4b932859253c49d76ea] # # patch "wiki/UsingCerts.mdwn" # from [9b4a3164a0691d5aba3e204f0d48371cbdcbee93] # to [085555165f627f23025f5cae8129fbe5311662ab] # # patch "wiki/VendorBranchPattern.mdwn" # from [c2d2272b8ed2f72f9c485e023a757fe45a23c87d] # to [05f7dfd5053b36427c582d17d8bb5354d68a2dd8] # # patch "wiki/VersionedPolicy/Archive.mdwn" # from [63b05f1787ea7c849eb363395a6b4fe7050ff0ad] # to [d941eeed55f2d7f53ae7c8695a07b6fd8832fa78] # # patch "wiki/VersionedPolicy/Comparison.mdwn" # from [f14d1727f008a301dfbd02c0d5deea0dfddca08c] # to [ec92935d6cf41883ceea13405adee556698529d2] # # patch "wiki/VersionedPolicy/Graydon.mdwn" # from [641a4364811070e7ca9ebb2abbf404891915adeb] # to [d63cacc1f3c72d94de7561d5287b85e29bb525b7] # # patch "wiki/VersionedPolicy/Interface.mdwn" # from [c195373b3dbe23b46b87ace73a7240089f8a139d] # to [11ac080bbd6d4bf8a8185d74202054ed87ce989f] # # patch "wiki/VersionedPolicy/SPKIWontWork.mdwn" # from [8226a01418a126a02e9c1db323940a79d1f165ec] # to [68582b766843abead050655fc766a9701eae3102] # # patch "wiki/VersionedPolicy/WorkList.mdwn" # from [44a31f4c28b6ea711abaaf0ec6818b33a6ed67fa] # to [9e72f901ac8ce1b12d301023bfc63ff1ae833dd7] # # patch "wiki/VersionedPolicy.mdwn" # from [58c9884c44f9dbb0c8b7464952023abab0be290a] # to [c63bb866a148f074effe22c8ffe841f3fd0a626d] # # patch "wiki/Win32DeviceFiles.mdwn" # from [656f9dd7656bc6c471fb6a65005fe254150da32d] # to [c1353e12c84d989b3287afc18bb94294ab3a4159] # # patch "wiki/WorkspaceConflicts.mdwn" # from [74cbd44290b147c417e1f8f08eb86f95e32da065] # to [d6e8b33e3bd331e1810e5a250ab9840de7a88f17] # # patch "wiki/ZeroConf.mdwn" # from [4b4bca4b49f668d8d0b74b582118d3bfcbb34393] # to [3042e2c268d5d8b67d55b7ba857e2cccdd742956] # # patch "wiki/elb.mdwn" # from [b415c8fa2c31eea6116bf260eb441a1228249b86] # to [287a6f9eb937e60a8bc62a26e566592b60c53f6c] # # patch "wiki/gwk.mdwn" # from [01740864701220850d18198cd541d35b77ca0207] # to [2fe0f357a10dacf8fe81771e80cd70a88f1da04b] # ============================================================ --- wiki/AttrUseCases.moin 2d4a515f1570b9b0742bc0405a481340175fba3f +++ wiki/AttrUseCases.mdwn 28ad729b1a091fd2bfcbf8b6aecf33bcbc19a010 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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: * turn on content encoding/decoding @@ -20,4 +22,4 @@ Why are attributes not more like certifi One thought immediately occurred to me when first starting to work with attributes: Why are attributes not more like certificates? They seem to express the same type of 'statements about something' only about files instead of revisions. Starting with the .26 series of monotone, the attributes are attached to the first class objects of file and directory types, so to me it would make sense to treat attributes as certificates on those objects, with all the same rules that apply for certificates too with respect to signing, selectors, automating etc. +I've been playing for a while with implementing bugtracking directly **inside** a working directory. Starting with the new attributes in .26 this has gotten a whole lot easier. Attributes can comfortably be used to say, when a bugreport is stored as a file in the working dir somewhere, attach extra metainfo to that bugreport through attributes. Having the bugreports directly revisioned and distributed like the code you're tracking bugs for has obvious advantages. -I've been playing for a while with implementing bugtracking directly '''inside''' a working directory. Starting with the new attributes in .26 this has gotten a whole lot easier. Attributes can comfortably be used to say, when a bugreport is stored as a file in the working dir somewhere, attach extra metainfo to that bugreport through attributes. Having the bugreports directly revisioned and distributed like the code you're tracking bugs for has obvious advantages. ============================================================ --- wiki/AutoInodeprints.moin e08af3462cb1553add68a59e456e6ba9c3778b88 +++ wiki/AutoInodeprints.mdwn 34e2067b3a72045144df0d3519db3b23ac0851cc @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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. So, we should consider: ============================================================ --- wiki/AutomateMagic.moin 2724845adddeba413546d3b0de606e72b4edfe46 +++ wiki/AutomateMagic.mdwn 9906e2fadd6fe925a4d0bf5ea413ea74ec491cc8 @@ -1,10 +1,12 @@ -=== Show log entries for a given SELECTOR === +[[tag migration-wip]] +### Show log entries for a given SELECTOR + {{{ $ mtn automate select SELECTOR | mtn automate toposort address@hidden | xargs -L1 mtn log --last=1 -r }}} -=== Query the root or tail revision of BRANCH === +### Query the root or tail revision of BRANCH {{{ $ mtn automate heads BRANCH | mtn automate ancestors address@hidden | mtn automate toposort address@hidden | head -n1 @@ -12,7 +14,7 @@ Optionally, add another {{{ | xargs -L1 Optionally, add another {{{ | xargs -L1 mtn ls certs}}} to query for the certs of the revision. -=== Find the base revision on another BRANCH === +### 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). ============================================================ --- wiki/AutomateVersions.moin 8fe4aed794a15346037232c734d1b406017aa7d6 +++ wiki/AutomateVersions.mdwn 4b8e9e7df7890ae77715d6f6f359eb32289906c3 @@ -1,15 +1,17 @@ +[[tag migration-wip]] + The rules to determine if the release version identifier X.Y is raised or not, are as follows: * the major number X increments whenever a backwards incompatible change is made * the minor number Y increments whenever any other change is made; it is reset to 0 when major number increments * either the major number X or the minor number Y increases at most once per release -== Interface Version Matrix == +## Interface Version Matrix The following table should give you an overview at which time certain functionalities have been added or altered in monotone's automation interface. -||'''monotone releases''' || 0.17 || 0.18 || 0.19 || 0.20-0.23 || 0.24-0.25 || 0.26 || 0.27 || 0.28 || 0.29 || 0.30 || 0.31-0.33 || 0.34 || 0.35 || 0.36 || 0.37-0.38 || 0.39-0.40 || -||'''interface versions''' || 0.0 || 0.1 || 0.2 || 1.0 || 1.1 || 2.0 || 2.1 || 2.2 || 3.0 || 3.1 || 4.0 || 4.1 || 4.3 || 5.0 || 6.0 || 7.0 || +||**monotone releases** || 0.17 || 0.18 || 0.19 || 0.20-0.23 || 0.24-0.25 || 0.26 || 0.27 || 0.28 || 0.29 || 0.30 || 0.31-0.33 || 0.34 || 0.35 || 0.36 || 0.37-0.38 || 0.39-0.40 || +||**interface versions** || 0.0 || 0.1 || 0.2 || 1.0 || 1.1 || 2.0 || 2.1 || 2.2 || 3.0 || 3.1 || 4.0 || 4.1 || 4.3 || 5.0 || 6.0 || 7.0 || ||ancestors || || || A || || || || || || || || || || || || || || ||ancestry_difference || || A || || || || || || || || || || || || || || || ||branches || || || || || || || || A || || || || || || || || || @@ -56,8 +58,8 @@ The following table should give you an o ||stdio || || || || A || || || || || || B || || || || || || || ||tags || || || || || || || || A || || || || || || || || || ||toposort || || A || || || || || || || || || || || || || || || -||'''interface versions''' || 0.0 || 0.1 || 0.2 || 1.0 || 1.1 || 2.0 || 2.1 || 2.2 || 3.0 || 3.1 || 4.0 || 4.1 || 4.3 || 5.0 || 6.0 || 7.0 || -||'''monotone releases''' || 0.17 || 0.18 || 0.19 || 0.20-0.23 || 0.24-0.25 || 0.26 || 0.27 || 0.28 || 0.29 || 0.30 || 0.31-0.33 || 0.34 || 0.35 || 0.36 || 0.37-0.38 || 0.39-0.40 || +||**interface versions** || 0.0 || 0.1 || 0.2 || 1.0 || 1.1 || 2.0 || 2.1 || 2.2 || 3.0 || 3.1 || 4.0 || 4.1 || 4.3 || 5.0 || 6.0 || 7.0 || +||**monotone releases** || 0.17 || 0.18 || 0.19 || 0.20-0.23 || 0.24-0.25 || 0.26 || 0.27 || 0.28 || 0.29 || 0.30 || 0.31-0.33 || 0.34 || 0.35 || 0.36 || 0.37-0.38 || 0.39-0.40 || A = Addition, B = Backwards-compatible change, C = Backwards-incompatible change ============================================================ --- wiki/AutomateWishlist.moin f3bb3bdae39ddb18e4ede0eeaeddb6cea8abdb84 +++ wiki/AutomateWishlist.mdwn 9e60a86c160b796410ad0dcbcb512bfe294bc090 @@ -1,12 +1,14 @@ +[[tag migration-wip]] + Missing (but useful) functions for the automate interface: * `ancestors`: limit the number of returned ancestors (like calling `parents` repeatedly) - * `branches`: returns the names of all branches. => How should that differ from `mtn ls branches`? - It would be callable from an automate stdio connection. ['''Implemented'''] + * `branches`: returns the names of all branches. => How should that differ from `mtn ls branches`? - It would be callable from an automate stdio connection. [**Implemented**] - * `diff`: returns the unified diff between two revisions. ['''Partially Implemented as automate content_diff'''] + * `diff`: returns the unified diff between two revisions. [**Partially Implemented as automate content_diff**] - * `roots`: returns all revision ids without parent. ['''Implemented'''] + * `roots`: returns all revision ids without parent. [**Implemented**] * `get_file_length ID`: returns the size of the specified file. Currently one has to fetch the whole file in order to find out its length. @@ -18,9 +20,9 @@ Missing (but useful) functions for the a * `get_option OPTION`: return the given option (where OPTION is "branch", "database", etc. - entries in _MTN/options) Clearly, anyone that wants to know these things can just grep them out of _MTN/options - but that's not really supported and is messing about with what are really monotone's internals. Knowing the DB monotone would use for a given workspace would be useful for GUIs. - ['''Implemented'''] + [**Implemented**] -== Extensions to support Graphical User Interfaces == +## Extensions to support Graphical User Interfaces -- MarcelvanderBoom [[DateTime(2006-06-18T18:39:06Z)]] Given the 'automate branches' example,the whole of the document linked to above, and the growing number of commands both in automate variety and in the normal interface (mtn heads for example), my wish would be that the 'normal' interface and the 'automate' interface become one; said another way: "get rid of the mtn automate command". Using a cmdline switch or a format specifier the output produced and the specifics of the effect can be steered. What 'callable from an automate stdio connection' means to a user: 'nothing'. @@ -30,21 +32,21 @@ and and {{{ mtn automate heads }}} -are the same thing, just formatted differently and as such i tend to look for an '''option''' to specify these formattings, not another '''command'''. Having something formatted as a plain rev list or basic io stanzas could be options to select quickly as they are used frequently. The document at berlios more or less says "give me all normal mtn commands, just in the automate interface" Why not do this in general? +are the same thing, just formatted differently and as such i tend to look for an **option** to specify these formattings, not another **command**. Having something formatted as a plain rev list or basic io stanzas could be options to select quickly as they are used frequently. The document at berlios more or less says "give me all normal mtn commands, just in the automate interface" Why not do this in general? -- ThomasKeller [[DateTime(2006-08-28T10:33:00Z)]] The only reason why all these commands must live inside the automation interface is because they need to be callable via automate stdio. If there would be a general refactoring which would allow the execution of any "normal" command via this interface, then this would be sufficient as well. Obviously if the automation interface would be removed in favor of a general implementation, one would need to think about where to move the current functionality from there, which does not exist in the normal interface. And for that purpose we'd need to make a big plan, and, I don't think anybody around here is keen on making big plans which take months to implement (if they're implemented at all). -== Automate Stdio Stream Mux == +## Automate Stdio Stream Mux -A large problem for current consumers of '''automate stdio''' is that this interface really only caters for the normal output of the command on the stdout stream. If the command produces some warning, errors, or even progress messages (like tickers, which may be useful for future automate commands), these are not well handled: +A large problem for current consumers of **automate stdio** is that this interface really only caters for the normal output of the command on the stdout stream. If the command produces some warning, errors, or even progress messages (like tickers, which may be useful for future automate commands), these are not well handled: * some errors and messages may interrupt the stdout stream, causing the client to get out of sync with the stdio record format * where multiple commands are called, it can be hard to tell which command caused which warning/error on stderr. * for either case, the content of the error message is not structured for program usage; it may even be changed based on the users language settings. -To address these problems, some changes and clarifications to the '''automate stdio''' output record format are proposed. +To address these problems, some changes and clarifications to the **automate stdio** output record format are proposed. The current form has the following description: @@ -81,11 +83,11 @@ The output consists of one or more packe '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'''. + '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'''. + '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'''. + '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. ============================================================ --- wiki/BasicIoFormalization.moin c0f2b9a879db4c1cb480a5cc71e2d75bd02c447c +++ wiki/BasicIoFormalization.mdwn 1a03eedc6b863debf07faf3103201420327e6d5c @@ -1,16 +1,18 @@ +[[tag migration-wip]] + 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. http://colabti.de/irclogger/irclogger_log/monotone?date=2005-11-25,Fri&sel=117#l194 Attempting to tame this discussion a bit... -= Concrete issues = +# Concrete issues Things that need some sort of resolution: - * whitespace normalization is AFAIK the ''only'' property that we don't verify is correct on incoming data. Since our policy is to verify everything, I would consider this a bug. + * whitespace normalization is AFAIK the *only* property that we don't verify is correct on incoming data. Since our policy is to verify everything, I would consider this a bug. -= Fuzzier stuff = +# Fuzzier stuff Arguments to make stanzas/lines first class items: * It seems unnecessarily confusing to have two somewhat different formats -- "basic_io" and "normalized basic_io"; especially since they're not clearly distinguished. @@ -23,7 +25,7 @@ Arguments to leave stanzas/lines as epip 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 = +# Empirical questions Is one formalism easier to code up a quick parser for? ============================================================ --- wiki/BestPractices.moin 9e4acb167835df9bbc9c7b3c6553c0b43407d6b9 +++ wiki/BestPractices.mdwn 2e172c2d23098a8623f44ea8a1a67db550a695ab @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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. ||CommitEarlyCommitOften || Making smaller changes makes it easier for others to pluck them || ============================================================ --- wiki/BranchAnalogy.moin 69abef4c1813f7a5818525da77e1d9fd086062e2 +++ wiki/BranchAnalogy.mdwn cc8a4bfd82b69aa080a21a7241208c6141307cda @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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: * in monotone, the revision history / ancestry graph is totally unrelated to the branch information: branches are not "editing branches" @@ -12,7 +14,7 @@ There are several important concepts in There are several important concepts in the above discussion. The following analogy may help new users grasp them. -= Ancestry = +# Ancestry The ancestry graph is like a family tree, documenting your genetic history. Each revision (person) has ancestors (parents). Most people have two (genetic) parents. In monotone most revisions record only one parent - the other parent is the unnamed working copy that had the changes being committed; revisions that result from merges have two recorded parents in the ancestry graph. @@ -27,7 +29,7 @@ Usually, when a new person is born, the Usually, when a new person is born, the doctor will sign a birth certificate containing various information about the person, such as the time and date of birth, and other similar things. In monotone, there are usually several certificates created on a new revision by default, and these certificates make similar statements about the new revision. -= Branch Membership = +# Branch Membership One of the certificates created by default in a new commit is a branch certificate, which is a statement about membership of the revision in a particular branch (which has a name). Branches are typically used to make statements about the suitability of particular revisions for particular purposes (such as being release-quality or experimental code, for example). Some commands in monotone look at branch certificates to help users select revisions for various purposes; these commands make working with monotone and common code-development practices more convenient, however you are not limited to only those common practices. @@ -44,19 +46,19 @@ You can start a whole new secret society You can start a whole new secret society of your own at any time by making a new branch certificate, either on an existing revision or as the initial branch certificate on your new child revision at commit time. Or you can leave off the branch certificate entirely and create a revision with no branch membership. -= Heads = +# Heads In monotone, the "heads" of a branch are all the revisions with a trusted branch certificate for that branch, and with no descendents also in that branch (even if they do have non-member children elsewhere). These are the people who stand to inherit the secret society's treasured collection of ancient artifacts, which are passed down along family lines -- but only amongst society members! There can be multiple heads, because different members all around the world can each produce children whenever they like, and induct them into the society. As above, news of new children or memberships sometimes travels slowly, and it's often the case that two different local chapters each think two different people are the sole heir until news of others arrives. -= Merge = +# Merge Just like for code development, it gets confusing for the society when there are too many inheritors, because the treasures really should stay together. It is best if the multiple inheritors can get together and produce a single heir with their combined genetic history to resolve this conundrum, though this doesn't have to happen immediately. Monotone includes a convenient command, `merge`, to find these heads and produce a rightful heir, complete with handy membership certificate. -= Propagate = +# Propagate Secret societies can be very focussed on a particular purpose, and if they stay isolated from developments in the wider world, they sometimes get a little in-bred; it's often a good idea for them to bring in some fresh genetic material from other parts of the ecosystem. This can happen when a society member produces a child with an outsider - the outsider might not join the society, but if the child is granted membership then their contribution has been added to the genetic pool of society members (and the child will be a new head for the branch, standing to inherit the ancient treasures). ============================================================ --- wiki/BranchNamingConventions.moin ca8b98456a645a38e80fb0e3d262ae21f3c7a391 +++ wiki/BranchNamingConventions.mdwn 195f41472ac53cb719e713fc95140febc5c1ccdd @@ -1,31 +1,33 @@ -There are a number of ways to create '''globally unique''' branch names. There's some debate about which one is best. +[[tag migration-wip]] +There are a number of ways to create **globally unique** branch names. There's some debate about which one is best. + Please add other options to all these lists, expand on pros/cons, add yourself to the Supporters list of things you like, etc... Keep in mind that several of the possible branch syntaxes require changes to selector syntax, so if there's a branch syntax you think is awesome, but all of the possible selector syntaxes that could be used with it make your teeth hurt... then the branch syntax probably wasn't so awesome. -= Branch syntax = +# Branch syntax [[Anchor(JavaStyle)]] -== Java style == +## Java style Example: `net.venge.monotone`, `net.venge.monotone.cvssync`, `com.gmail.accountname.project` What we currently recommend. Many people object to the reversed domain names. No way to do email-based branches, though some use their email address for a "hostname". This only becomes a "problem" when an actual hostname shares the accountname *and* hosts monotone projects as well. [[Anchor(clennox1)]] - CraigLennox: Unfortunately, this style puts `net.venge.monotone.gcc4` and `net.venge.monotone.gui` in the same namespace relative to `net.venge.monotone`. At a minimum there needs to be syntax to disambiguate the ancestrial hierarchy from the categorical hierarchy, so that it becomes possible to avoid netsyncing much more than is necessary to get either a single project or a single line of development across multiple projects ('''especially''' when pulling from very large sites). + CraigLennox: Unfortunately, this style puts `net.venge.monotone.gcc4` and `net.venge.monotone.gui` in the same namespace relative to `net.venge.monotone`. At a minimum there needs to be syntax to disambiguate the ancestrial hierarchy from the categorical hierarchy, so that it becomes possible to avoid netsyncing much more than is necessary to get either a single project or a single line of development across multiple projects (**especially** when pulling from very large sites). Supporters: ["arcatan"], ChadWalstrom, ["gwk"] -== Hierarchy by Separator == +## Hierarchy by Separator There are a number of suggestions that consistently use the same general syntax to introduce hierarchy. The only difference between these suggestions is the separator character. The generic format is: Syntax: `{IDENTIFIER|FQDN|RFQDN|EMAILADDR}[{SEP}PROJECT[{SEP}SUBPROJECT[...]]]{SEP}{BRANCH}` The choice of the separator character has many implications, from selector character collision to filesystem side-affects during checkout. The generic benefits for this format include disambiguation between host name and branch name, and the ability to introduce project and sub-project hierarchy relationships between branches. The identifier preceeding the project and branch can be just about anything, as long as it has a reasonable chance to be evaluated as unique amongst the user base. -=== Hierarchy by / === +### Hierarchy by / (was "Sorta URL style") Example: `venge.net/monotone`, `venge.net/monotone/cvssync`, address@hidden/newproj` @@ -38,20 +40,20 @@ Supporters: MatthewNicholson, EricAnders Supporters: MatthewNicholson, EricAnderson, DanielThompson -=== Hierarchy by : === +### Hierarchy by : (was "classic mac style") Example: `venge.net:monotone`, `venge.net:monotone:cvssync`, address@hidden:newproj` Suggested by RichardLevitte. Doesn't look similar to URLs and confuse people, while still allowing a more natural order to things. Requires changes to selector syntax. -''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 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) -=== Hierarchy by # === +### Hierarchy by # Example: `MyCompanyInc#project#branch`, `venge.net#monotone`, `net.venge#monotone#cvssync`, address@hidden @@ -59,11 +61,11 @@ Supporters: ChadWalstrom Supporters: ChadWalstrom -== Hierarchy by mixed separators == +## Hierarchy by mixed separators Using mixed separators would allow more flexibility in distinguishing between branches and subprojects. Examples: `net.venge.monotone/contrib/mtsh`, `net.venge.monotone#rosters#netsync` -== monotone-specific URL style == +## monotone-specific URL style Example: `monotone-branch://venge.net/monotone`, `monotone-branch://venge.net/monotone/cvssync`, `monotone-branch://address@hidden/newproj` @@ -79,7 +81,7 @@ DanielThompson: I would claim that addin TimothyBrownawell: I would suggest supporting URLs of `mtn://hostname/branchname` . This would provide the convenience of having URLs without the problems of having the transport type or host name be part of the branch name. -== standard URLs style == +## standard URLs style Example: `http://venge.net/monotone`, `http://venge.net/monotone/cvssync` @@ -91,7 +93,7 @@ Supporters: Supporters: -== URI/URN style == +## URI/URN style Example: `mtnb:venge.net/monotone`, `mtnb:venge.net:monotone/cvssync`, `mtnb:address@hidden:branch/name/here` @@ -100,7 +102,7 @@ Supporters: Supporters: -== emails galore == +## emails galore Example: address@hidden, address@hidden, address@hidden @@ -111,7 +113,7 @@ Suggested by Nathan Myers. Simple, avoid 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 = +# 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). @@ -121,7 +123,7 @@ 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%? + * *{{{%}}} -- 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: @@ -132,14 +134,14 @@ The mac-style one requires replacing :, * `b~venge.net:monotone/address@hidden * `b,venge.net:monotone/a,address@hidden -== Straw poll == +## Straw poll Stick in your name and your opinion: * HugoMills: The URL/URI-style names have the advantage that things like XML, RDF and OWL all expect such names, so you don't have to mangle or change anything later if one of those technologies is used in some tool. * KennethPerry: Also if the URL/URI style names was used, things like a monotone kioslave for KDE would fit (similar to the svn:// kioslave). * NathanielSmith: I kind of like the forms with `~` or `,` as replacements for `/`. The `~` is more visually distinctive, and `,` has already associated meaning of "sequencing" a la MagicSelectors (but disappears visually more easily). - * ChadWalstrom: Branch names should not be transport dependent or interfere with transport naming. I do think it's important to note that that conventions should work ''with'' but not be enforced ''by'' the tool, unless it is done via hooks in lua. GNU Arch enforced naming conventions for its branches, which reflected its historical storage mechanism: directories of tarballs containing (uber) patches. This met with a lot of resistance with potential users (and even current users, myself included), especially those not interested in learning the internals and "why's" of naming conventions. + * ChadWalstrom: Branch names should not be transport dependent or interfere with transport naming. I do think it's important to note that that conventions should work *with* but not be enforced *by* the tool, unless it is done via hooks in lua. GNU Arch enforced naming conventions for its branches, which reflected its historical storage mechanism: directories of tarballs containing (uber) patches. This met with a lot of resistance with potential users (and even current users, myself included), especially those not interested in learning the internals and "why's" of naming conventions. * CraigLennox: I favour changing as little as possible while addressing the real problem of namespace overload (which I describe at [#JavaStyle Java Style] above). This ought to be achievable without having to change the selector syntax. * ["gwk"]: Java style (I'm a Java programmer...) it's nice and easy to read and type no shift etc. * ExampleUser: I think [....] ============================================================ --- wiki/BranchRenaming.moin a0d5788f425f769f52ee6e2beb1ffa1fc6c965cd +++ wiki/BranchRenaming.mdwn b8db5634de32b04faa1fbc0a90b3a7d0d6675e0b @@ -1,7 +1,9 @@ -''NB: patches to integrate this information into the manual proper would be gratefully accepted'' +[[tag migration-wip]] -= Renaming Monotone Branches = +*NB: patches to integrate this information into the manual proper would be gratefully accepted* +# Renaming Monotone Branches + 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. @@ -33,7 +35,7 @@ mtn cmd args... | while read REV; do mtn cmd args... | while read REV; do }}} -= Branch Renaming Script = +# 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. {{{ @@ -62,7 +64,7 @@ mtn -d $MTN_DB db kill_branch_certs_loca }}} -= Using A Ruby Shell To Manipulate Branches = +# 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 ============================================================ --- wiki/BranchStatuses.moin 812a0cacf85649e9048dd5565cc999419caeba14 +++ wiki/BranchStatuses.mdwn 3a294c70d9cc293ad71216673176a8b8e46bb793 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + Currently active development branches: -= n.v.m.cvssync (outdated) = +# n.v.m.cvssync (outdated) Contact: ChristofPetig @@ -12,7 +14,7 @@ See also CvsSyncHints. See also CvsSyncHints. -= n.v.m.cvssync.refactor = +# n.v.m.cvssync.refactor Contact: ChristofPetig @@ -35,7 +37,7 @@ What can be put into mainline: * the mtn_automate class (C++ wrapper library to access monotone via automate) * the mtn_cvs directory infrastucture can be put into mainline but can wait as well until it's finished -= n.v.m.git = +# n.v.m.git Contact: PetrBaudis @@ -43,7 +45,7 @@ Status: I'm not quite sure. Petr? (ms) Status: I'm not quite sure. Petr? (ms) hasn't been touched for awhile, stalled. -= n.v.m.levitte.select-heads-of = +# n.v.m.levitte.select-heads-of Contact: RichardLevitte @@ -51,7 +53,7 @@ Status: Blocked on figuring out the righ Status: Blocked on figuring out the right way to integrate this cleanly with the rest of the selector functionality. See MagicSelectors. -= n.v.m.levitte.usher = +# n.v.m.levitte.usher Contact: RichardLevitte Created: 2006-02-28 @@ -60,7 +62,7 @@ Status: Work in progress Status: Work in progress -= n.v.m.experiment.iface-refactor = +# n.v.m.experiment.iface-refactor Contact: NathanielSmith @@ -72,7 +74,7 @@ Status: Work in progress. Status: Work in progress. -= n.v.m.annotate = +# n.v.m.annotate Contact: EmileSnyder @@ -84,7 +86,7 @@ Status: Work in progress. Status: Work in progress. -= n.v.m.debian = +# n.v.m.debian Contact: MatthewNicholson @@ -92,7 +94,7 @@ Status: Merged into mainline. Status: Merged into mainline. -= n.v.m.cvsimport-branch-reconstruction = +# n.v.m.cvsimport-branch-reconstruction Contact: MarkusSchiltknecht @@ -100,7 +102,7 @@ Status: Still close to completion :-) - Status: Still close to completion :-) - for more details, see CvsImport -= n.v.m.experiment.db-compaction = +# n.v.m.experiment.db-compaction Contact: MarkusSchiltknecht @@ -108,7 +110,7 @@ Status: landed on mainline Status: landed on mainline -= n.v.m.experiment.encapsulation = +# n.v.m.experiment.encapsulation Contact: ZackWeinberg @@ -116,7 +118,7 @@ Status: landed on mainline Status: landed on mainline -= n.v.m.partialpull and n.v.m.gaps = +# n.v.m.partialpull and n.v.m.gaps Contact: ChristofPetig and MarkusSchiltknecht respectively @@ -126,7 +128,7 @@ Status: Experimentation Status: Experimentation -= n.v.m.botan = +# n.v.m.botan Contact: MarkusSchiltknecht or TimothyBrownawell @@ -134,7 +136,7 @@ Status: Botan version 1.7.4 landed on ma Status: Botan version 1.7.4 landed on mainline. -= n.v.m.botan.system-switch = +# n.v.m.botan.system-switch Contact: MarkusSchiltknecht @@ -142,7 +144,7 @@ Status: Experimentation Status: Experimentation -= n.v.m.svn_import = +# n.v.m.svn_import Contact: MarkusSchiltknecht @@ -150,7 +152,7 @@ Status: Experimentation Status: Experimentation -= n.v.m.heights = +# n.v.m.heights Contact: ThomasMoschny @@ -158,7 +160,7 @@ Status: Currently merged into mainline. Status: Currently merged into mainline. -= n.v.m.revision_diff = +# n.v.m.revision_diff Contact: ThomasKeller @@ -166,7 +168,7 @@ Status: Stalled for quite a long time, b Status: Stalled for quite a long time, because there hasn't yet been an consensus if this should really be the "official" format mtn should use to express external changesets - primarily because once this is set into stone we certainly want an "automate apply_diff" command to complement this functionality. We also still have to find a way to express binary deltas within this new format to make it really useful for the "apply_diff" use case. -= n.v.m.commit_without_-b = +# n.v.m.commit_without_-b Contact: ThomasKeller @@ -179,7 +181,7 @@ Status: Stalled, decide what to do with Status: Stalled, decide what to do with all that. -= n.v.m.experiment.informal_messages_to_stdio = +# n.v.m.experiment.informal_messages_to_stdio Contact: ThomasKeller @@ -187,7 +189,7 @@ Status: Doesn't compile, not even alpha Status: Doesn't compile, not even alpha state. Hope to find some time for this on the next summit. -= n.v.m.automate-netsync and n.v.m.automate-stdio-ticker = +# n.v.m.automate-netsync and n.v.m.automate-stdio-ticker Contact: ThomasKeller @@ -195,7 +197,7 @@ Status: Unusable, should probably be sus Status: Unusable, should probably be suspended and/or redone from scratch (and maybe rethought even when / if n.v.m.nuskool gets ready?) -= n.v.m.lapo.color = +# n.v.m.lapo.color Contact: LapoLuchini @@ -203,7 +205,7 @@ Status: rough and experimental Status: rough and experimental -= n.v.m.automate_show_conflict = +# n.v.m.automate_show_conflict Contact: StephenLeake @@ -213,7 +215,7 @@ Status: Just started; 'automate show_con Status: Just started; 'automate show_conflicts' works for "file added on left and right" case. Need to add all other conflict cases. -= n.v.m.experimental.win32_pipes = +# n.v.m.experimental.win32_pipes Contact: StephenLeake @@ -229,7 +231,7 @@ Status: on hold; use Cygwin instead, whe Status: on hold; use Cygwin instead, where things just work. -= n.v.m.experimental.win32_pipes_2 = +# n.v.m.experimental.win32_pipes_2 Contact: StephenLeake @@ -243,10 +245,10 @@ Status: on hold; no actual work beyond p Status: on hold; no actual work beyond planning done. -= n.v.m.TEMPLATE = +# n.v.m.TEMPLATE Contact: WikiName -''Synopsis'' +*Synopsis* Status: ============================================================ --- wiki/BranchUI.moin 5897ef1838f3d13d94953899703b12e59a1c225e +++ wiki/BranchUI.mdwn 880da7619aff3fb0e3683611f80cb784502774c6 @@ -1,5 +1,7 @@ -= Idea 1 = +[[tag migration-wip]] +# Idea 1 + Have a command "branch". Usage: * `monotone branch foo.bar`: switch working copy to be foo.bar (simply modifies MT/options). * `monotone branch -r REV foo.bar`: mark rev REV as being in branch foo.bar (simply issues a branch cert) @@ -7,11 +9,11 @@ In all cases give the user feedback on w In all cases give the user feedback on whether they have created a new branch or not. -= Idea 2 = +# Idea 2 "propagate " could note/warn that a new "newbranch" will be created, and behave the same as "cert h:somebranch branch newbranch". -= Idea 3 = +# Idea 3 Some user experience: http://xaraya.com/pipermail/xaraya_devel/2006-January/002512.html @@ -21,6 +23,6 @@ Perhaps we should provide a `switch` com * if that branch exists, does `update -b BRANCH -r h:` * if not, switches the working copy to be on BRANCH -= Idea 4 = +# Idea 4 +*your idea here* -''your idea here'' ============================================================ --- wiki/BugSquashingParty.moin 2e9e6b95e37d59ece66e2e74822907d7717a2d2a +++ wiki/BugSquashingParty.mdwn 9fc823e6825667b2d40881fe08c01d3330cd6b67 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + We're talking about having a Bug Squashing Party this weekend (November 26-27), with the goal of getting rosters merged. Participation requires some knowledge of C++ or at least shell, but no prior experience with monotone internals -- if you've been curious about getting more involved, this might be a great way to start! ============================================================ --- wiki/BuildBot.moin 7c24a658a87cec3360d3091a91c5a834a9cbbb3f +++ wiki/BuildBot.mdwn 100b7b92675080b560373def21c47a846a80039d @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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. General information: http://buildbot.net @@ -21,7 +23,7 @@ See BuildBotWindows for setting up a Bui See BuildBotWindows for setting up a Buildslave on Windows -= Setting up a Buildslave for Monotone = +# Setting up a Buildslave for Monotone 1. Install Twisted from http://twistedmatrix.com/trac/ and buildbot from http://buildbot.sourceforge.net/ (and apply the above patch) @@ -55,11 +57,11 @@ See BuildBotWindows for setting up a Bui 1. Make sure that permissions are correct. The mtbuildbot user needs write access to slave-dir, and should not have write access to anything else. -== Running the Buildslave == +## Running the Buildslave There are several ways to run a buildslave. Here are a few examples: -=== Running the Buildslave with cron === +### Running the Buildslave with cron 1. Start the slave now: {{{# su mtbuildbot -c 'buildbot start slave-dir' @@ -71,7 +73,7 @@ There are several ways to run a buildsla {{{# echo '@reboot buildbot start slave-dir' | su mtbuildbot -c 'crontab -e -' }}} -=== Running the Buildslave with runit === +### Running the Buildslave with runit 1. Install runit, http://smarden.org/runit or apt-get install runit or whatever. @@ -95,7 +97,7 @@ exec nice twistd --nodaemon --no_save -y {{{# echo '@reboot runsv .' | su mtbuildbot -c 'crontab -e -' }}} -= Monotone Buildbot Wishlist = +# Monotone Buildbot Wishlist * cygwin * better BSD coverage (all we have ATM is one part time freebsd buildslave) @@ -106,7 +108,7 @@ exec nice twistd --nodaemon --no_save -y * any other systems we don't have, but where you think monotone should work -- AIX? HP-UX? QNX? ReactOS? you tell me... -= Setting up a Buildbot for your own Project using Monotone = +# Setting up a Buildbot for your own Project using Monotone Currently, you will need the above patch for buildbot to work with monotone. Make sure to make yourself familiar with the buildbot infrastructure, they have a nice manual: http://buildbot.sourceforge.net/manual-0.7.5.html ============================================================ --- wiki/BuildingOnMac.moin 8e18c22e92eb6a0b0d2bad3a4ea7065821787771 +++ wiki/BuildingOnMac.mdwn cbec17ebfa915d864e1b1c79d830e760c4e795c1 @@ -1,12 +1,14 @@ +[[tag migration-wip]] + Building Monotone on Mac OS/X -= Installing the toolchain = +# Installing the toolchain Monotone's makefile has to be generated using special GNU tools. Tiger (OS/X 10.4) does not have the required versions of these tools in the standard installation, though XCode 2.4.1 comes with an adequate version of the C++ compiler itself (older XCode versions have been known to be buggy). -One way to get and build the latest versions of GNU tools is to get them from the [http://www.macports.org/ MacPorts (previously known as Darwin Ports)] project. Install the porting application from http://svn.macports.org/repository/macports/downloads/ and it will put a program called "port" into your ''/opt/local/bin'' directory. When you run this program as an administrator, it installs and builds the latest versions of GNU tools into that same directory. +One way to get and build the latest versions of GNU tools is to get them from the [http://www.macports.org/ MacPorts (previously known as Darwin Ports)] project. Install the porting application from http://svn.macports.org/repository/macports/downloads/ and it will put a program called "port" into your */opt/local/bin* directory. When you run this program as an administrator, it installs and builds the latest versions of GNU tools into that same directory. -(if ''/opt/local/bin'' is not in your path, you can add it in a terminal shell by typing ''PATH=/opt/local/bin:$PATH'') +(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): {{{ @@ -17,14 +19,14 @@ Once you have installed the port tool, r % 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). +# 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: +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" }}} -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). +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: {{{ @@ -43,10 +45,10 @@ Once you have a working monotone, then t % monotone --db=mt.db --branch=net.venge.monotone checkout monotone-sources }}} -This will take a while to download. Once it comes you will have to build it (in the same way described above). But when you pull down this source it will not have a configure script, so you will need to run ''autoreconf --install'' to generate it. +This will take a while to download. Once it comes you will have to build it (in the same way described above). But when you pull down this source it will not have a configure script, so you will need to run *autoreconf --install* to generate it. -= Using Xcode = +# Using Xcode The GNU tools do not have an option to generate a .xcodeproj alongside your makefile (the way [http://doc.trolltech.com/4.0/qmake-manual.html Qmake] can). If you're just building, stick with the command line. But if you're going to be doing editing, building, and debugging, you'll probably want to use Xcode, so: @@ -71,23 +73,23 @@ It shouldn't say "" for the add -= Things to look out for = +# Things to look out for * As of 2006-01-22, boost from darwinports is not linked with the correct install_name [http://bugzilla.opendarwin.org/show_bug.cgi?id=5533 (darwinports bug 5533)]. Linking statically should still work, or compile it yourself -* If you are linking to boost statically and ./configure can't see the libs, try running ''ranlib *.a'' on the Boost library files to update the archive indexes. +* If you are linking to boost statically and ./configure can't see the libs, try running *ranlib *.a* on the Boost library files to update the archive indexes. -* As of xcode 2.3 (gcc build 5341), -ggdb will generate dwarf debugging symbols. The size of a compile dir will be significantly (4x?) smaller with dwarf, so -ggdb is recommended. Note however that Shark doesn't seem to handle dwarf debugging symbols (as of 4.3.3) - you might want to explicitly give ''-gstabs''. +* As of xcode 2.3 (gcc build 5341), -ggdb will generate dwarf debugging symbols. The size of a compile dir will be significantly (4x?) smaller with dwarf, so -ggdb is recommended. Note however that Shark doesn't seem to handle dwarf debugging symbols (as of 4.3.3) - you might want to explicitly give *-gstabs*. -= Building a universal binary = +# Building a universal binary . -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''. +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 }}} -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. +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. +The *-fno-threadsafe-statics* works around a Apple gcc bug (4227885) that causes dramatic performance decreases accessing static variables. *-dead_strip* and *-gfull* are used to avoid linking in code that isn't used, reducing the binary size. -The ''-fno-threadsafe-statics'' works around a Apple gcc bug (4227885) that causes dramatic performance decreases accessing static variables. ''-dead_strip'' and ''-gfull'' are used to avoid linking in code that isn't used, reducing the binary size. ============================================================ --- wiki/BuildingOnSolaris.moin a3534a897e8126fde927e9c9966da24a9a3bf574 +++ wiki/BuildingOnSolaris.mdwn c8bfbc121048baa94dc5d7a6f808fe9a30d533f3 @@ -1,22 +1,24 @@ -= GCC build = +[[tag migration-wip]] + +# 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. If you have some guidelines for gcc, please post them here. Feedback welcome. Thanks! -= Sun Studio build = -== Compiler == +# Sun Studio build +## Compiler The official build environment on Solaris is Sun Studio 10 and 11, of which the latter can be got at no charge on [http://developers.sun.com/prodtech/cc/products/get.html Sun's Website] (not free software). You'll also need all [http://developers.sun.com/prodtech/cc/downloads/patches/ss11_patches.html available patches] for the compiler for your platform. -== Boost == +## Boost If you use Boost 1.34 and Studio 11 with latest patches or Studio 12, no patches are necessary anymore! 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 == +## 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). -=== Locales === +### 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. @@ -25,13 +27,13 @@ If you really want locales, and want to If you really want locales, and want to avoid the trouble with gnu iconv, fetch the net.venge.monotone.portable-gettext-support branch. It should be complete enough to give you locales, but it's missing developer tools support without which it can't be merged into mainline (and thus, release). -== Issues == +## Issues I don't know what other issues there are. If any come up, please post them here. -= Running as Server = +# Running as Server -== Solaris Service Management Facility == +## Solaris Service Management Facility (address@hidden, 2007-06-11) Sun Solaris 10 introduced the "service management facility" (SMF) to replace the well-known, but arcane rc scripts. In addition to start, stop, and (optional) restart methods, it allows to define dependencies between services, sources of documentation and other meta information about the service. Each service is described in a single XML file that can be imported into the system's service repository. Here is the SMF XML file that I wrote for a monotone netsync service: ============================================================ --- wiki/BuildingOnWindows/VC8.moin cc2cfccb331742343b64e1836ef6dbd3d1436139 +++ wiki/BuildingOnWindows/VC8.mdwn bdd4f56d523bc78d3e5a377140ab3aaf7d629f6a @@ -1,4 +1,6 @@ -= Installing the toolchain = +[[tag migration-wip]] + +# Installing the toolchain This section is preliminary setup--once this has been completed once, you can rebuild monotone regularly using only the instructions in the next section. @@ -10,9 +12,9 @@ section. ||iconv||1.9.2||http://gnuwin32.sourceforge.net/downlinks/libiconv.php|| ||zlib||1.2.3||http://gnuwin32.sourceforge.net/downlinks/zlib.php|| - * ''Newer versions of the tools listed above are likely to work without too much trouble.'' + * *Newer versions of the tools listed above are likely to work without too much trouble.* -=== Installation instructions === +### Installation instructions 1. Visual C++ 2005 Express Edition - full install. @@ -28,7 +30,7 @@ section. 1. boost - follow the VS8 instructions here: http://boost.org/more/getting_started.html -= Building monotone = +# Building monotone 1. Install a pre-built monotone binary from http://venge.net/monotone/downloads/ 1. Follow the self-hosting instructions at http://venge.net/monotone/self-hosting.html to get a copy of the monotone repository. ============================================================ --- wiki/BuildingOnWindows/VisualC8.moin d598f53c08ce10e7405e13f34a375decb133f778 +++ wiki/BuildingOnWindows/VisualC8.mdwn bdbfab37f2165a12c375a5aa4dce84077e6a43cf @@ -1,5 +1,7 @@ -= Installing the toolchain = +[[tag migration-wip]] +# Installing the toolchain + This section is preliminary setup--once this has been completed once, you can rebuild monotone regularly using only the instructions in the next section. @@ -11,9 +13,9 @@ section. ||iconv||1.9.2||http://gnuwin32.sourceforge.net/downlinks/libiconv.php|| ||zlib||1.2.3||http://gnuwin32.sourceforge.net/downlinks/zlib.php|| - * ''Newer versions of the tools listed above are likely to work without too much trouble.'' + * *Newer versions of the tools listed above are likely to work without too much trouble.* -=== Installation instructions === +### Installation instructions 1. Visual C++ 2005 Express Edition - full install. @@ -29,7 +31,7 @@ section. 1. boost - follow the VS8 instructions here: http://boost.org/more/getting_started.html -= Building monotone = +# Building monotone 1. Install a pre-built monotone binary from http://venge.net/monotone/downloads/ 1. Follow the self-hosting instructions at http://venge.net/monotone/self-hosting.html to get a copy of the monotone repository. ============================================================ --- wiki/BuildingViaPkgsrc.moin 3b33859830e445df2fc2095c4b7ae2affa06f134 +++ wiki/BuildingViaPkgsrc.mdwn d2a5a7207282a2b62df155cfe6916250faa52b47 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + 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. -= About pkgsrc = +# About pkgsrc The [http://www.netbsd.org/Documentation/software/packages.html pkgsrc framework] supports building third-party application software packages on a large number of platforms. It is the default package management system for [http://www.netbsd.org NetBSD] and [http://www.dragonflybsd.org DragonFlyBSD], and supports many [http://www.netbsd.org/Documentation/software/packages.html#platforms other platforms] as well, including Linux, Solaris, Irix and other Unix variants, and Interix (Microsoft Windows Services for Unix). @@ -10,7 +12,7 @@ Pre-built binary packages for a selectio Pre-built binary packages for a selection of platforms are maintained by volunteers, and these can save you some compile time if one happens to be available for you, but otherwise pkgsrc will fetch and build the package and all its dependencies from source for you. -= Bootstrapping pkgsrc = +# Bootstrapping pkgsrc If you're running on NetBSD or DragonFlyBSD, your system already comes with the base pkgsrc infrastructure (and you're probably already familiar with using it). @@ -20,7 +22,7 @@ After bootstrapping, there are some basi After bootstrapping, there are some basic [http://www.netbsd.org/Documentation/pkgsrc/configuring.html configuration ] steps to do (though mostly the defaults will be fine), and then you can use pkgsrc to build and install thousands of useful third-party applications and tools. -= Building monotone = +# 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: {{{ @@ -30,8 +32,8 @@ There are also packages for many other I There are also packages for many other InterfacesFrontendsAndTools that work with monotone. -NetBSD is known for its broad portability, and strives for the same principle in pkgsrc. However, not all packages build on all platforms (though a surprising and ever-increasing number do), almost always because of underlying portability problems in the third-party software packages and dependencies themselves. Regular ''bulk builds'' of all packages are done on a number of platforms to catch such problems, but you may be unlucky. If you find a platform where the monotone package doesn't build, please submit a [http://www.netbsd.org/Misc/send-pr.html#submitting bug report] in the pkg category. +NetBSD is known for its broad portability, and strives for the same principle in pkgsrc. However, not all packages build on all platforms (though a surprising and ever-increasing number do), almost always because of underlying portability problems in the third-party software packages and dependencies themselves. Regular *bulk builds* of all packages are done on a number of platforms to catch such problems, but you may be unlucky. If you find a platform where the monotone package doesn't build, please submit a [http://www.netbsd.org/Misc/send-pr.html#submitting bug report] in the pkg category. -= using pkg_chk = +# using pkg_chk Rather than adding and updating packages individually, the [http://pkgsrc.se/pkgtools/pkg_chk pkg_chk] utility can be used to remember which packages you want installed and keep them up to date. ============================================================ --- wiki/CarrotAndStick.moin cdde4c203d05d2a72f52e4e3b86a5991436cd507 +++ wiki/CarrotAndStick.mdwn dd68135ee164e40b236eabafd71a9d4b9702d511 @@ -1,10 +1,12 @@ +[[tag migration-wip]] + In order to form a more perfect UI... -= Empirical data = +# Empirical data We don't actually know very much about how people use monotone in the wild! How silly is that? -'''Plan''': keep a log in ~/.monotone/ of every command run. We should be very careful here to only log information that is not confidential. (E.g., need to check with community whether they consider branch names confidential. If very useful information is considered by some people to be confidentical, then fail safe -- default to not logging it, and provide a way for users who want to help, to enable more detailed logging. Alternatively, only enable the system at all if requested by a hook.) +**Plan**: keep a log in ~/.monotone/ of every command run. We should be very careful here to only log information that is not confidential. (E.g., need to check with community whether they consider branch names confidential. If very useful information is considered by some people to be confidentical, then fail safe -- default to not logging it, and provide a way for users who want to help, to enable more detailed logging. Alternatively, only enable the system at all if requested by a hook.) Log in particular start time of each run, the command run, plus provide a way for code to add arbitrary other things to the log. (Example: it would be useful to log, for each merge, information on whether conflicts were found, and what they are.) @@ -14,7 +16,7 @@ Perhaps have monotone check the size of Perhaps have monotone check the size of this file on startup, and if it is growing large, suggest the user send it in? Or possibly simply rotate it every once in a while, throwing out old stuff, so even if the user doesn't send it in, the space use is bounded? -= Involve the user = +# Involve the user Once we have the above, add several commands: * a way to express displeasure. `monotone punish`, `monotone stab`, `monotone die`, ...? @@ -23,7 +25,7 @@ These commands react appropriately on st * a way to make comments, that's a little less intrusive and ritual-laden as filing a bug report or sending an email to the list. `monotone whine`, `monotone complain`, `monotone say`, `monotone suggest`? `monotone oops`, tell people to make a note whenever they make a mistake, even if they think it's their fault? (give your comment on the command line, or else have it pop up an editor a la `commit`) -= Enabling = +# Enabling Perhaps the way to do this is to have the logging disabled by default, but have * the --help for the above commands describe how to turn it on @@ -31,11 +33,11 @@ The goal being to have it be as discover * if any of the "purer" feedback commands are run with it turned off, then give an error message, and describe how to turn on the feedback functionality The goal being to have it be as discoverable and require as little thought as possible -- and perhaps catch people right when they _are_ frustrated or happy, and perhaps will be most receptive to anything that suggests how they can help us help them. -= Getting the feedback = +# Getting the feedback It is most convenient if the user does not have to do anything tricky to send feedback. Sending email is kind of hard. Perhaps we could use a HTTP(S) POST? (The [http://www.cs.wisc.edu/cbi/ CBI] folks get away with doing this after every program run. There are some sneaky bits too, like the response to the POST can tell the program to switch to a different URL, or shut down posting altogether -- useful if you want to stop receiving information, ever!) Probably we shouldn't do it every program run. Possibly we should do it after any of the direct feedback commands, and have a command that just sends feedback without prompting for a complaint. It might make sense, if the user has enabled this, to just automatically do the POST whenever our local buffer gets large enough... but if the network is down, this could cause monotone itself to misbehave in a user-visible way, which is bad for a pure feedback mechanism. -= Testing = +# Testing What are the implications for testing? @@ -43,7 +45,7 @@ What are the implications for testing? * We need to be able to re-enable it and force the output into a particular place, in order to test the collection * We need some way to test the feedback mechanism -- how do we test POSTing to a URL? (I guess there are various ways to run a tiny HTTP server, e.g. in a few lines of python, or even something crazy involving bash and netcat...) -= Privacy = +# Privacy How much information do we record? Not file contents, obviously. Are file/directory names sensitive? Are branch and key names sensitive? Server names? changelog messages (which may occur on the command line, too)? ============================================================ --- wiki/CaseInsensitiveFilesystems.moin ed3bdd8d05b0625558c8a29e0d72abac456fc17a +++ wiki/CaseInsensitiveFilesystems.mdwn 399c68b79dd983fa10befc1f14d63b6e9cd67696 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + Discussion: irc logger missed it, but, in #monotone around 2005-12-12T00:00:00 UTC. -= Problems = +# Problems * I have a revision with files Potato.c and poTato.c. When I check it out, or update to it, on win32 or osx, either we silently screw things up, or we simply fail. (Find out which!) The latter would be better than the former, but neither is particularly appetizing. * Proposed solution: extend MergeViaWorkingDir support to signal these like they were rename conflicts; this lets the user perform their checkout and then straighten things out. This also would be applicable in the cases where there is random junk in the user's tree, that we don't want to clobber on update. ============================================================ --- wiki/CertCleanup.moin c47fd639b8465493a96065fe6dc36e12ea7086ef +++ wiki/CertCleanup.mdwn c719e5fe06aab7d1b9c58e1aee6528573f6b69c1 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + While we're doing VersionedPolicy, we probably want to take the opportunity to clean up some stuff about how we do certs. Some thoughts: ============================================================ --- wiki/ChadWalstrom.moin 5ae7f609607231dd8a8429ebdafd94a11448e435 +++ wiki/ChadWalstrom.mdwn d5766ac6ec33842ae18443b6cc37ae5dae8b093a @@ -1,3 +1,5 @@ +[[tag migration-wip]] + GNU Arch refugee since monotone 0.18. * [[MailTo(chewie AT wookimus DOT net)]] * http://wookimus.net/~chewie ============================================================ --- wiki/ChangeLog.moin 7ae6cc3b924c08cbe32cd85f74aec76697ca6a29 +++ wiki/ChangeLog.mdwn a41c6e2186c7baf99020cb9ec77d639d1f573b1c @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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. ============================================================ --- wiki/CherryPicking.moin 1d4f82bab5129c0293f8ceee7b6c18f0cfea9a16 +++ wiki/CherryPicking.mdwn 02db5fd6b04b151328347871f745a57dd7259713 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + "Cherry picking" is an extension to merge that allows changes between arbitrary versions to be merged into the current version. Merging is an inherently heuristic process, and cherry-picking merge even more so; not all changes make sense in every context, so no implementation of cherry picking can be perfect. Nonetheless it's an option for some revision control systems that has been a TODO item for Monotone for some time (see the FAQ). ============================================================ --- wiki/ChristofPetig.moin 307ebcf0bf77c77c1ab7fc4041ac9f44fd6ffe6e +++ wiki/ChristofPetig.mdwn 68bfdf45f079aca4a14eff4e883a9448b770b367 @@ -1 +1,3 @@ +[[tag migration-wip]] + E-Mail: address@hidden ============================================================ --- wiki/CraigLennox.moin b3b5cd92610b50b0c40a750654f5956964cf6363 +++ wiki/CraigLennox.mdwn 0d58a96602111ae00ab7dae7fa6c4b1c68ca8ffd @@ -1 +1,3 @@ +[[tag migration-wip]] + I've been a happy user of Monotone since 0.15. ============================================================ --- wiki/CreatingBranches.moin 4604514e5fbbbac792bed9166495397a6e819735 +++ wiki/CreatingBranches.mdwn b1f7c9b4e653c3dfda3fbf2e83ac428f8792f0f5 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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. {{{ ============================================================ --- wiki/CvsImport.moin 3d5dcd92ea387b33e0a7746faf25937599da0a70 +++ wiki/CvsImport.mdwn 4ce058f21673400073d7007b050cff953342aa90 @@ -1,8 +1,10 @@ -= Importing CVS repositories with Graph Based Algorithms = +[[tag migration-wip]] +# Importing CVS repositories with Graph Based Algorithms + The cvs2svn people, mainly Michael Haggerty have come up with a new algorithm (see his [http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1451 mail]) for cvs2svn 2.0, which is based on [http://en.wikipedia.org/wiki/Graph_theory GraphTheory]. In the branch net.venge.monotone.cvsimport-branch-reconstruction, MarkusSchiltknecht maintains an implementation in C++, with some monotone specific modifications. -== Overview == +## Overview An import consists of three steps: @@ -11,7 +13,7 @@ An import consists of three steps: * streamline the graph, to resolve branch affiliation * consuming the blobs in the graph to create monotone revisions -== Parsing the RCS files == +## Parsing the RCS files In a first step, the RCS files are parsed to generate file deltas and hashes. In all subsequent steps, files are only referred to by the hash, which allows us to do most CVS conversions in memory (as an example, importing the mozilla repository peaked at around 1.8 gb memory usage, last time I tried). Additionally, we also collect all cvs_events into blobs. Such cvs_events (which should probably better be called rcs_events) can be: @@ -33,7 +35,7 @@ After this step, the dependency graph lo [http://www.bluegap.ch/samples/importing_cvs_small_real_repo/t1.png] -== Splitting dependency cycles == +## Splitting dependency cycles In a second step, we check the graph for dependency cycles using a depth first search. Upon discovery of such a cycle, we try to find the best split point, to split one blob of that cycle into two. The simplest, and currently used method is splitting at the largest gap in time. This is repeated until no more cycles are left, we then have an acyclic graph, but not a tree - meaning there can still be cross or forward edges. @@ -42,7 +44,7 @@ See such a dependency cycle highlighted [http://www.bluegap.ch/samples/importing_cvs_cycle_splitter2/t2.png] -== Streamlining the graph == +## Streamlining the graph To figure out in what branch a certain blob belongs to, we'd like to get a tree of branches. Additionally, as CVS - unlike monotone - cannot represent multiple heads and merges, we'd like to eliminate all cross or forward edges. We do that in various ways, ... to be described... @@ -50,7 +52,7 @@ A sample for such a cross or forward edg [http://www.bluegap.ch/samples/importing_cvs_small_real_repo/t7.png] -== Consuming the blobs == +## Consuming the blobs As we now have a tree of blobs (revisions), it's trivial to import that into monotone. See the streamlined graphs from our two example unit tests, first the simpler cycle_splitter2: @@ -61,7 +63,7 @@ And here the small_real_repo in all its [http://www.bluegap.ch/samples/importing_cvs_small_real_repo/t8.png] -== Another Sample, from importing_cvs_cycle_splitter3 == +## Another Sample, from importing_cvs_cycle_splitter3 Involving cycles with branch starts: @@ -73,7 +75,7 @@ Involving cycles with branch starts: * [http://www.bluegap.ch/samples/importing_cvs_cycle_splitter3/cvs_graph.all.6.png final graph, importable by monotone] -== Real World test repositories, and how they are currently failing == +## Real World test repositories, and how they are currently failing Tested with: 040f83b3bcd4c04adc7e3947d06a9ccffc223ad5 2008-05-01T14:00:49 ============================================================ --- wiki/CvsSync.moin 3bc2bc0b23d7a4d9d92bd1a5ed82bf3fbf9dab0f +++ wiki/CvsSync.mdwn 92804911fad04a6f54fa3c3eafd8e46ecdd729a2 @@ -1 +1,3 @@ +[[tag migration-wip]] + see CvsSyncHints and CvsSyn3 ============================================================ --- wiki/CvsSync3.moin 1328aa4f58d623e4d2e30e55d543ca7d4de8d980 +++ wiki/CvsSync3.mdwn 73333f0252e0c030af2a6d7ac44108c199989e3b @@ -1,5 +1,7 @@ -= CvsSync rewrite #3 = +[[tag migration-wip]] +# CvsSync rewrite #3 + This page just serves as a notepad to introduce you to the more esoteric features of cvssync3. - CvsSync3 uses attributes to store information about file revisions and metadata and directory metadata. Repository metadata is stored as root directory attributes. ============================================================ --- wiki/DagBasedRefinement.moin 37da0c8d23a1a51c371a90c8e9482baf67c8edd7 +++ wiki/DagBasedRefinement.mdwn 12853aa0f5827d4b57db17d7c60130296f808027 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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/DatabaseLocking.moin 10a3ab523a33216b9943e9113308a30bbbc364be +++ wiki/DatabaseLocking.mdwn 4de6bde9707ce9f70e2961118222959bb01c1af4 @@ -1,5 +1,7 @@ -''(source discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-12-08,Thu&sel=90#l151)'' +[[tag migration-wip]] +*(source discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-12-08,Thu&sel=90#l151)* + Discussion of database locking in Monotone, problems and suggested solutions. When monotone code needs to start a transaction, it instansiates "transaction_guard". By default this leads to execution of the SQL statement "BEGIN EXCLUSIVE". Transaction guards can also be created in a non-exclusive mode; in this case "BEGIN DEFERRED" is run. This should only be done if it is believed no database writes will be performed. @@ -10,12 +12,12 @@ Sqlite does save us from "dirty" reads; Sqlite does save us from "dirty" reads; a dirty read is seeing uncommitted writes in another transaction. -= Use cases = +# Use cases * (from njs) e.g., "monotone diff | less monotone commit" -> crash, db is locked * ViewMTN calls monotone a lot, only to do reads. It can't access the db when the database is being updated with "monotone pull". -= Ways forward = +# Ways forward 15:22 <@njs> "In the current implementation, the RESERVED lock is also released, but that is not essential. Future versions of SQLite might provide a "CHECKPOINT" SQL command that will commit all changes made so far within a transaction but retain the RESERVED lock so that additional changes can be made without given any other process an opportunity to write." 15:22 <@njs> ^^ sounds like what we've been wanting... ============================================================ --- wiki/DeltaStorageStrategies/ShootOut.moin dd0b0d51efc27bc72c6825e27875ef28f83428ad +++ wiki/DeltaStorageStrategies/ShootOut.mdwn 6f52fe1f30481dce1482e63225e8ea2066b9cee5 @@ -1,9 +1,11 @@ -|| ''When the going gets tough, the tough get empirical.'' || +[[tag migration-wip]] +|| *When the going gets tough, the tough get empirical.* || + So, we have a few prototypes, now what? How do we choose? -= candidates = +# candidates All candidates should run with blob support and appropriate block size, since these could potentially have non-linear effects. @@ -11,28 +13,28 @@ All candidates should run with blob supp * against-base * linear forward chaining * linear forward chaining with skips or breaks - * classic [http://www.selenic.com/mercurial/wiki/index.cgi/Design#head-ef542bce2b68f24d275e7908636317491f678648 revlogs] ("classic" in that cmason is doing [http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/5407 a bunch of playing around] with different sorts of revlogs right now too; not in the sense that we use ''exactly'' this design, since for the prototype at least we're doing a few tricks differently) + * classic [http://www.selenic.com/mercurial/wiki/index.cgi/Design#head-ef542bce2b68f24d275e7908636317491f678648 revlogs] ("classic" in that cmason is doing [http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/5407 a bunch of playing around] with different sorts of revlogs right now too; not in the sense that we use *exactly* this design, since for the prototype at least we're doing a few tricks differently) A big question is how much tuning should be done on these. The goal is to get an idea of how the technique would perform in a "proper implementation", but without spending ages of time super-optimizing each possibility before we even know if it's worth it or not. So we should do the things that would seem to make a qualitative difference. E.g., it's probably worth making sure that netsync is smart enough to avoid reconstructing versions when actually unnecessary. A big question: is it worth implementing the lookup-chains-by-rowid optimizations that drh suggested for these tests? In principle they should not affect locality _much_, since we are not VACUUMing, but avoiding traversing indexes should be a win of some magnitude. * When profiling checkouts and pulls there doesn't seem to be a significantly amount of (wait-)time spent in things that look index-related for sqlite (An exception is when the database hasn't been ANALYZEd recently). It's possible that I'm not looking at the right callstacks though. - Matt Johnston -= testing methodology = +# testing methodology We should test both full pulls, and repeated incremental pulls, since the various methods may interact in complicated ways with repeated incremental pulls. (These can screw up disk locality in various ways, cause non-optimal ordering for forced delta linearization like classic revlogs do, etc.) -So, for each test dataset, we have a single db. Call this PRISTINE-0. >From this, we use `db kill_rev_locally` repeatedly to produce smaller and smaller dbs, PRISTINE-1, PRISTINE-2, PRISTINE-3, etc. PRISTINE-''n+1'' is produced by taking PRISTINE-''n'', and repeatedly running `automate leaves`, picking a random item, and `db kill_rev_locally` on it. I'm not sure how many revs we should remove each time, or how many of these sets we should generate. Note that the randomness here impacts reproducibility; either save these databases so everyone can re-run the tests using the same dbs, or specify the random seed used. +So, for each test dataset, we have a single db. Call this PRISTINE-0. >From this, we use `db kill_rev_locally` repeatedly to produce smaller and smaller dbs, PRISTINE-1, PRISTINE-2, PRISTINE-3, etc. PRISTINE-*n+1* is produced by taking PRISTINE-*n*, and repeatedly running `automate leaves`, picking a random item, and `db kill_rev_locally` on it. I'm not sure how many revs we should remove each time, or how many of these sets we should generate. Note that the randomness here impacts reproducibility; either save these databases so everyone can re-run the tests using the same dbs, or specify the random seed used. Up until this point, everything can be done with just a random mainline version of monotone. -Now, for each ''n'', serve up PRISTINE-''n'' using mainline, and pull it into a fresh db using the version under test. Call the result TEST-''n''. These are the databases we will actually use for testing. +Now, for each *n*, serve up PRISTINE-*n* using mainline, and pull it into a fresh db using the version under test. Call the result TEST-*n*. These are the databases we will actually use for testing. Now, measure the following things: * pulling TEST-0 into a fresh database. Measure server CPU time, client CPU and real time, and bytes transferred. Measure size of resulting db (both `du` and `du -a`, for the revlog case), and time for a cold-cache checkout, and time for a hot-cache checkout. And time for a cold cache `log --diffs --last=20`, and same on hot cache. (To do a cold-cache checkout on linux, put the database into a separate partition, then umount that partition, re-mount it, and immediately run a checkout from it.) - * pulling each of the TEST-''n'' databases into a single database -- to simulate a user tracking a project by doing a daily incremental pull. Measure the size of the resulting db (`du` and `du -a` again), and time for a cold-cache checkout, and time for a hot-cache checkout, and hot and cold `log --diffs --last=20`. (Maybe measure the time each pull takes too?) Finally, measure the server CPU time, client CPU and real time, for doing a fresh pull ''from'' the incrementally pulled database. (This simulates the db a server would generally have, produced by incremental pushes.) + * pulling each of the TEST-*n* databases into a single database -- to simulate a user tracking a project by doing a daily incremental pull. Measure the size of the resulting db (`du` and `du -a` again), and time for a cold-cache checkout, and time for a hot-cache checkout, and hot and cold `log --diffs --last=20`. (Maybe measure the time each pull takes too?) Finally, measure the server CPU time, client CPU and real time, for doing a fresh pull *from* the incrementally pulled database. (This simulates the db a server would generally have, produced by incremental pushes.) -= data sets = +# data sets Some interesting ones: * `net.venge.monotone*` @@ -42,7 +44,7 @@ Some interesting ones: * CTWM -- http://ctwm.free.lp.se/monotone-crash-course.html (tiny all around) * something big in both tree and history... anyone got a kernel import around to play with? -= questions = +# questions * is the above candidate set appropriate? are we confident these are the interesting contenders? * "skips or breaks" -- which should we do? both? what is actually implemented? @@ -52,13 +54,13 @@ Some interesting ones: * do we have a kernel-ish history available to test scalability on? * who will do this work? individual tasks: * make sure each candidate works - * '''msh'''?: forward chaining and against-base - * '''graydon'''?: revlogs - * '''?''': make sure netsync is smart about letting the db do the work - * '''?''': write the scripts to actually run a monotone on one of these data sets, i.e. implement the methodology section + * **msh**?: forward chaining and against-base + * **graydon**?: revlogs + * **?**: make sure netsync is smart about letting the db do the work + * **?**: write the scripts to actually run a monotone on one of these data sets, i.e. implement the methodology section * au.asn.ucc.matt.monotone.shootout has a "mkpristine.py" script for creating PRISTINE-N dbs. - * '''?''': procure a big scalability data set, like get a kernel import or something. cvs_import isn't so good for this, because we want realistic branching... maybe the bk import tool someone posted to the list recently would be useful, or porting git_import to rosters (shouldn't be too hard)... - * '''?''': actually get all of the different configurations together and run the tests on a single machine. This might actually be several people, just to make sure that things don't vary wildly between OSes (e.g., OS X has surprised us in the past). - * '''njs''': organize all of the above, point of contact for figuring out what to do next and keeping track of who knows what + * **?**: procure a big scalability data set, like get a kernel import or something. cvs_import isn't so good for this, because we want realistic branching... maybe the bk import tool someone posted to the list recently would be useful, or porting git_import to rosters (shouldn't be too hard)... + * **?**: actually get all of the different configurations together and run the tests on a single machine. This might actually be several people, just to make sure that things don't vary wildly between OSes (e.g., OS X has surprised us in the past). + * **njs**: organize all of the above, point of contact for figuring out what to do next and keeping track of who knows what It is more important to get some numbers than to get perfect numbers, so probably the most important thing is to get the script working, and then to get the candidates basically working, and the last priority is getting super-good data sets. ============================================================ --- wiki/DeltaStorageStrategies.moin bd9cbd626092970d68005364aff90008380ecac4 +++ wiki/DeltaStorageStrategies.mdwn d798bb1c080834f4d9f15a5f5a30d4f9f077769d @@ -1,5 +1,7 @@ -Here are some of the known ways one ''could'' potentially do delta-compression on large version corpora. +[[tag migration-wip]] +Here are some of the known ways one *could* potentially do delta-compression on large version corpora. + * backwards linear-chained deltas (like classical monotone) * backwards linear-chained deltas with occasional full-text breaks * forwards linear-chained deltas @@ -10,9 +12,9 @@ Here are some of the known ways one ''co * whatever it is git uses to find similar items -- sorting by size or something? * tree-structured storage -- using the inexplicably-not-well-known trick for storing strings as trees, one can share subtrees. Josh cites EXODUS and SDS2 (see 2.2 of the thesis) as using this trick, and there are some other interesting cites in the same section. * several of these mechanisms can be applied either to a forced-linear history (like hg uses), or allowing forks (and merges?) to appear in the reconstruction graph. Josh actually claims that that forced-linear time ordering gave him smaller deltas than RCS-style-topology branched deltas, on his test case (FreeBSD CVS history -- I guess they must have a lot of bug-fixes applied to multiple branches or the like?). - * weaves (actually, these should maybe be thought of a sub-case of tree-structured storage -- with a different perspective) -- as traditionally implemented, I think these get ''excellent'' compression, because you have to rewrite your whole weave on every change, so you might as well compress the whole thing at once, and that gives your compressor much more to work with than a delta-chaining approach. (Unless you batch up your deltas somehow.) + * weaves (actually, these should maybe be thought of a sub-case of tree-structured storage -- with a different perspective) -- as traditionally implemented, I think these get *excellent* compression, because you have to rewrite your whole weave on every change, so you might as well compress the whole thing at once, and that gives your compressor much more to work with than a delta-chaining approach. (Unless you batch up your deltas somehow.) -= Random thoughts = +# Random thoughts xdelta actually supports multiple-source deltas totally straightforwardly -- basically you just use all the sources as potential places to draw strings out of in COPY operations. is this useful at all? @@ -22,13 +24,13 @@ Chaining, skip-deltas, and against-base Chaining, skip-deltas, and against-base all seem to be special cases of some more general family of algorithms -- they're all trying to pick some rule that will balance compression against reconstruction cost. Surely none of these particular three points are at the global optimum of the fitness function for this class? And I observe that the competing variables we want to optimize for are simple to measure as we go on the actual data we're trying to store... (i.e., we can in principle calculate how many seeks, how many bytes, etc., we are using, and make decisions based on that.) -= Interaction with netsync = +# Interaction with netsync -Netsync wants to send simple forward linear-chained deltas. Reconstructing other things from these can be very expensive (e.g., what we do now to get backward linear-chained deltas, where we not only reverse every delta, but we store each full version to the db and then remove it again when the next delta comes in!). Against base deltas might be doable here (when considering the compression mentioned below), though making sure the other side has the base adds some amount of complexity, and I'm not sure how well this works when the receiving side ''does'' have some files already. +Netsync wants to send simple forward linear-chained deltas. Reconstructing other things from these can be very expensive (e.g., what we do now to get backward linear-chained deltas, where we not only reverse every delta, but we store each full version to the db and then remove it again when the next delta comes in!). Against base deltas might be doable here (when considering the compression mentioned below), though making sure the other side has the base adds some amount of complexity, and I'm not sure how well this works when the receiving side *does* have some files already. Netsync also wants to send exactly what is in the source's db, to minimize load on servers. -== Forward versus Reverse Linear Chains == +## Forward versus Reverse Linear Chains The advantage of reverse linear chains seems to be that the most common accesses (check-outs) are against the end of the chain which in a reverse linear chain means there are no deltas to @@ -42,13 +44,13 @@ cache and thus avoid the long delta chai the benefit of a forward chain and check-outs can usually be fulfilled from cache and thus avoid the long delta chains. -== Interaction with zlib compression == +## Interaction with zlib compression To counteract increased netsync traffic using against-base deltas, applying zlib to the entire stream (rather than per-packet) seems to make against-base deltas comparable to linear deltas. (I think this requires the assumption that we send related deltas together at netsync time, i.e. sort by file.) See the au.asn.ucc.matt.monotone.test-deltas branch in the main venge.net repository for a test script and [http://matt.ucc.asn.au/monotone/delta-screenshot.txt sample output]. -== Size comparison for against-base deltas == +## Size comparison for against-base deltas 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): @@ -60,7 +62,7 @@ So this is fairly consistent with drh's }}} 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 == +## Revlog variations http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/5407 @@ -70,10 +72,10 @@ http://thread.gmane.org/gmane.comp.versi http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/5862 -= Random thought on space locality using current sqlite functionality = +# Random thought on space locality using current sqlite functionality Store a whole revlog-style whole-base+deltas span (a revlog actually consists of many of these spans, but you tend to access them sort of independently) in a single sqlite row. In an ideal world, sqlite would let us read/write from such rows directly (possibly without allowing us to change their size), and we could store all deltas in such thingies. Maybe even mmap them. In this world, we would probably have to keep the latest deltas split up into separate rows like now, but could archive old ones into more compact and seek-friendly storage this way. (I am only assuming that if we allocate a whole large blob at once, it will end up contiguous on disk.) -= Shootout = +# Shootout How do we choose? DeltaStorageStrategies/ShootOut ============================================================ --- wiki/DerekScherger.moin f22501976e4e878a786edf6221944d2527a69234 +++ wiki/DerekScherger.mdwn 7c23559593fcc0b960f0a6af6ce6a4f0e7371b5a @@ -1,6 +1,8 @@ +[[tag migration-wip]] + #format wiki #language en -== Your Name == +## Your Name Email: [[MailTo(address@hidden)]] [[BR]] IRC nick: dscherger ============================================================ --- wiki/DevGroup.moin 3e26e8355833e3b04744c6b893e6c98dcee3edec +++ wiki/DevGroup.mdwn 0aa37b3c943fd9489bae7d72a5e7b5364076f178 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + #acl DevGroup:admin,read,write All:read Anyone listed on this page can edit this page. Anyone listed on this page is automatically given admin rights on this wiki, and in particular the ability to protect/unprotect pages from editing, and delete nonsense pages. Anyone listed on this page should feel free to add other people that should be listed on it, if you're missing I probably just didn't know the wikiname to use... ============================================================ --- wiki/EmileSnyder.moin 2e482b3b818313e543baa791c73e927930004ba7 +++ wiki/EmileSnyder.mdwn aa9316ddc5d5b96ce1bb42a4b1fa97da566938d5 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + #format wiki #language en -== Emile Snyder == +## Emile Snyder Email: [[MailTo(address@hidden)]] [[BR]] IRC nick: esnyder ============================================================ --- wiki/EssentialMonotone.moin f1ecd084a3c201cb3ff9fdc9208b24bf5b1c709a +++ wiki/EssentialMonotone.mdwn faf145c09aed47b366d630a5c00f4e3b016322fd @@ -1,12 +1,14 @@ +[[tag migration-wip]] + What is the bare minimum command set needed to use monotone? For read-only/"anonymous" tracking of an existing project: Initial setup: - `mtn pull --new-db --db `''project''`.mtn `''host'' ''branch*wildcard'': do an initial fetch + `mtn pull --new-db --db `*project*`.mtn `*host* *branch*wildcard*: do an initial fetch - `mtn checkout -b `''branch'' ''directory'': check out latest source + `mtn checkout -b `*branch* *directory*: check out latest source Updating: @@ -18,11 +20,11 @@ For contributing: Initial setup: - `mtn genkey` ''address@hidden'': introduce yourself to monotone (only run this once ever, then copy around the file ~/.monotone/keys/''address@hidden'') + `mtn genkey` address@hidden: introduce yourself to monotone (only run this once ever, then copy around the file ~/.monotone/keys/address@hidden) - `mtn pull --new-db --db `''project''`.mtn `''host'' ''branch*wildcard*'': do an initial fetch + `mtn pull --new-db --db `*project*`.mtn `*host* *branch*wildcard**: do an initial fetch - `mtn checkout -b `''branch'' ''directory'': check out latest source + `mtn checkout -b `*branch* *directory*: check out latest source Commiting: ============================================================ --- wiki/Feature/AccessControl.moin 8f7c9fe5d34752bad05c8c3007c49f0a8fc20fda +++ wiki/Feature/AccessControl.mdwn 602447a5122d82a14117f80dfdf3a1e89f5551cb @@ -1,24 +1,26 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Provide Access Control features to provide limits over the actions developers can take -= Supported = +# Supported -Monotone has extensive and extremely powerful features for deciding which developer actions should be accepted. However, they're quite unusual and quite different from what other systems offer. So much so that people coming from existing VCS tools (especially centralised ones) might not even ''recognise'' them as Access Control features at first. +Monotone has extensive and extremely powerful features for deciding which developer actions should be accepted. However, they're quite unusual and quite different from what other systems offer. So much so that people coming from existing VCS tools (especially centralised ones) might not even *recognise* them as Access Control features at first. In monotone, it is far more important what comes out of the db than what goes in. These features concentrate much less on restricting what a developer can do or say or publish into the repository, and much more on giving the end user the power to be selective about how and when they use that information later. Network exchange is a simple communication of facts (file contents and revisions) and assertions about their value (in certs) - but those assertions may not necessarily be believed. The TrustFoundations page describes how these concepts work in more detail. There are simple netsync permission hooks that mediate basic access control to servers, but everything else is better done via trust evaluations at the time of usage. In part this is a recognition of the unavoidable consequences of the offline, distributed nature of the system - any programmatic attempt to restrict software behaviour is subject to tampering by someone in full control of their own system and database contents. But it turns out to be a far better way to deal with a number of other requirements as well. -Access controls are applied by users over what revisions and developers' code can come ''out'' of the database and have access to their workspace. Users can have different workspaces, for different purposes, with different trust settings appropriate to each purpose - taking revisions and information from the same database. New assertions can be made about old revisions at any time, and these may change how and where those revisions are considered trusted. +Access controls are applied by users over what revisions and developers' code can come *out* of the database and have access to their workspace. Users can have different workspaces, for different purposes, with different trust settings appropriate to each purpose - taking revisions and information from the same database. New assertions can be made about old revisions at any time, and these may change how and where those revisions are considered trusted. For example, a common use for these kinds of features in other VCS tools is to restrict commits in specialised branches to a limited number of approved committers. In a centralised system, these controls would be enforced by a MasterRepository. Release Branches are a common example, where a release engineering team must review and approve all changes. In monotone, the revision can be committed first, published, then reviewed, and finally `approve`d onto the release branch by someone developers trust to make statements about code quality for that branch. This is just one example, and the capabilities are very powerful indeed. However, the flip-side of this unusual approach is that few projects are accustomed to working this way, and many users don't want to have to configure these kinds of rules for themselves. Monotone allows a very distributed and loosely structured development community to share information much more readily than they might with other tools, but many projects are more structured and generally involve certain authority figures who most users are happy to delegate these trust decisions to. The next major feature development effort in monotone, now that the core VCS functionality is robust and stable and mostly complete, is a set of VersionedPolicy mechanisms. This will allow users to delegate the configuration of these trust decisions to a suitable project authority or authorities for the sake of simplicity and convenience. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * TrustFoundations and UsingCerts ============================================================ --- wiki/Feature/AtomicCommit.moin 469132dcb1d0fb699a76631859bc0ea9e6ceb6ae +++ wiki/Feature/AtomicCommit.mdwn 25ad516ced4862d86105b75d4ec61c49effc9a19 @@ -1,24 +1,26 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Commits to multiple files and directories happen all at once, as a single cohesive change set in isolation from other changes. -= Supported = +# Supported Monotone commits are atomic and each produces a discrete revision. -In addition, you can `commit` at any time to record the current state of your workspace safely. Monotone supports (and encourages) multiple ''heads''. You don't have to worry about whether your workspace or repository are up to date with respect to other developers' changes, and you don't have to be interrupted by a need to merge your work with other changes before you can commit. Merging happens as a separate step, when you are ready, and you can always go back to the starting point you just committed if the merge turns out to be difficult. +In addition, you can `commit` at any time to record the current state of your workspace safely. Monotone supports (and encourages) multiple *heads*. You don't have to worry about whether your workspace or repository are up to date with respect to other developers' changes, and you don't have to be interrupted by a need to merge your work with other changes before you can commit. Merging happens as a separate step, when you are ready, and you can always go back to the starting point you just committed if the merge turns out to be difficult. Commits are atomic both in the VCS sense of a single revision across the entire file tree, as above, and also in the database sense: see FeatureRobustRepository. -= Example Usage = +# Example Usage {{{ $ mtn commit }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Dealing-with-a-Fork Dealing with a Fork] ============================================================ --- wiki/Feature/BuildIntegration.moin 2dd9641c27e5a6c155f65eb2a07df3fda444f892 +++ wiki/Feature/BuildIntegration.mdwn be9278519c0ab85a38f369d6870d40fa34b967f6 @@ -1,17 +1,19 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description It should be possible to trigger build and test systems to react to commits. -= Supported = +# Supported Monotone has extensive hook and trigger facilities using lua. Monotone uses BuildBot for its own build-testing infrastructure, integration of other systems like Tinderbox should be quite simple. Contributions of script snippets and configuration documents are welcome! Monotone is designed from the start to be integrated with other tools, to support distributed workflow and project development processes. UsingCerts, in particular `testresult` certs, such QA tools can publish their results for each revision back to the distributed development community, who can then depend on these results when choosing suitable code to work with. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Quality-Assurance Quality Assurance] ============================================================ --- wiki/Feature/CVSExport.moin ef43adf7b60c45efe9bebafd0fd9cc69f4d58841 +++ wiki/Feature/CVSExport.mdwn df4ff494269e75202d77a795b5e2e68342bafc6a @@ -1,10 +1,12 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Put revisions committed to monotone back into a CVS repository, to allow gradual migration or support interaction between projects using different tools. -= Not (yet) Supported = +# Not (yet) Supported This is not yet supported in mainline monotone, but there is experimental code on a branch which does this (see BranchStatuses). @@ -12,7 +14,7 @@ It is an explicit goal of this developme It is an explicit goal of this development effort to eventually support replication of this kind with multiple different repositories, whether CVS or other VCS tools, including relaying changes between them via monotone. That ambitious goal is still some way off, however. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureCVSExport VCSFeatureCVSExport] ============================================================ --- wiki/Feature/CVSImport.moin cab653a8e28ccc3be9552b893ead580eeb91a68b +++ wiki/Feature/CVSImport.mdwn 5c6300c9fe93bb2590b185e4444478c09a1c7a80 @@ -1,16 +1,18 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The ability to import past project history from CVS and make it available to future development (so that diff, log, and other operations work as expected. -= Partially Supported = +# Partially Supported monotone can import cvs history, including collecting together changes in multiple files into synthesised change sets. The `cvs_import` command provides this feature; this is just one of several ways of working with ["MonotoneAndCVS"]. The primary limitation is that CVS branches are presently not attached to the revisions they branched off from: each is an independent linear history. Work is underway to resolve this limitation. -= Example Usage = +# Example Usage To import a full CVS history, you need a copy of the cvsroot `,v` files: {{{ @@ -19,7 +21,7 @@ This will create a branch called `org.pr 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`. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Importing-from-CVS Importing from CVS] ============================================================ --- wiki/Feature/CommitMail.moin fb5b17ceb5b3bf9a695dda9d061588219009da12 +++ wiki/Feature/CommitMail.mdwn 67ec4dcec228783fc0eb8b18a14be89f7c3c1c38 @@ -1,16 +1,18 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Commits should trigger email notifications with the commit log message and details of the changes -= Supported = +# Supported Monotone supports this and many similar kinds of actions and triggers via hooks. There is a hook that can be invoked on commit, but this will run on the individual developer's machine where the commit is done offline. It would be more usual to generate these messages instead when the committed revisions arrive via netsync at a convenient public server (see MasterRepository) with the appropriate email infrastructure. Monotone also includes a hook implementation for emitting events to [http://cia.navi.cx/stats/project/monotone CIA], from where the notifications can also be sent to IRC channels and RSS feeds. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Hooks Event Notification Hooks] ============================================================ --- wiki/Feature/CompactRepository.moin a7eb23003f1e60e43667394887705a52fb89bc18 +++ wiki/Feature/CompactRepository.mdwn 98b623ce12da9e23ac4543f5baaedf73a76706e9 @@ -1,16 +1,18 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The repository storage format should be compact and efficient, so that it is convenient for developers to keep replicated copies. -= Supported = +# Supported Monotone compresses file and delta storage with gzip before writing to the database. For typical source file content and large projects with long histories, the resulting database file is usually similar or smaller than the corresponding CVS `,v` files. Storage size has not been a particularly strong development focus, and some information is stored uncompressed for fast indexing and searching. Further efforts at more compact storage forms could be made, but are not considered particularly important for size results alone at this stage given the already good results - such changes may happen in the course of making performance or other improvements as well. Monotone's storage format is also very convenient: it is a single [http://www.sqlite.org SQLite] database file (by convention with a `.mtn` extension). There are no trees of history files consuming inodes in hidden/dot directories scattered throughout the workspace. One database can be shared between many workspaces on the same machine, so there is no need to duplicate the history storage when working on several independent changes or along several different branches, each in their own workspace. Each workspace has a single `_MTN` metadata directory at the root, with a handful of small files, one of which includes a reference to the database to use for operations within the workspace. -A number of useful and important operations can be performed on the database file without ''any'' workspace, so long as arguments normally inherited from the workspace are provided explicitly: network `sync` operations, branching and merging, diffs between revisions, log review, and others. +A number of useful and important operations can be performed on the database file without *any* workspace, so long as arguments normally inherited from the workspace are provided explicitly: network `sync` operations, branching and merging, diffs between revisions, log review, and others. The database format is machine- and endian-independant, and so databases can be quickly copied between machines where necessary or useful, including as a potential communication channel. History can be transferred or recovered from a copy of a db file on a CD or DVD, as one example. @@ -29,7 +31,7 @@ See also: FeatureRobustRepository ## $ mtn -d monotone.mtn co -b net.venge.monotone.experiment.foo ## }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: ============================================================ --- wiki/Feature/EmbeddedIDs.moin 5e31f7b8fe2e8e5981fd37021776c4f3f7ce6589 +++ wiki/Feature/EmbeddedIDs.mdwn b1dd19db90df9c62f18d6a979fd84e4a82f825f0 @@ -1,18 +1,20 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The ability to embed in file content the revision ID of the revision it came from. This is useful for identifying the source when the file becomes detached from the workspace and from monotone, such as when it is used to generate a derivative form (like an executable or html-rendered web page), or if the file has been imported into another project's VCS. -= Partially Supported = +# Partially Supported Monotone does not directly support automatic expansion of version strings or other keywords inside file content. Because the SHA-1 hashes of file content are crucial, and because these kinds of flags have proved difficult and confusing in some other systems, implementation of this feature has been avoided up to now -- mostly for lack of a compelling use case. It is certainly possible to add. -Some of the cases where this kind of feature is used in other systems are better addressed by other mechanisms in monotone; in particular it is considered better practice to use the overall revision of the tree rather than a per-file identifier. Monotone uses this for its own embedded version in the executable, accessed via ``mtn --full-version``. Because monotone supports distributed, offline operation, there is also less need for embedded identifiers to determine a file's revision status. Finally, a file's SHA-1 hash '''is''' its identifier, so unchanged files can be identified in this manner. +Some of the cases where this kind of feature is used in other systems are better addressed by other mechanisms in monotone; in particular it is considered better practice to use the overall revision of the tree rather than a per-file identifier. Monotone uses this for its own embedded version in the executable, accessed via ``mtn --full-version``. Because monotone supports distributed, offline operation, there is also less need for embedded identifiers to determine a file's revision status. Finally, a file's SHA-1 hash **is** its identifier, so unchanged files can be identified in this manner. It is possible to approximate this feature, if needed, using hooks. A custom attr could be attached to files that need such expansion, and an attr-hook defined in lua to perform the substitution. Another possibility may be an implementation similar to that used to handle platform-specific newline formats, generalising that to other kinds of filters. In any such implementation, it would be vital to ensure that the content of the file seen for commit has been sanitised to contain only the bare keyword in a 'canonical' form that is stable between revisions. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureDollarFreeBSD VCSFeatureDollarFreeBSD] ============================================================ --- wiki/Feature/Fast.moin f1f75891942a3cb75dce7f4e56d86e505bc5be52 +++ wiki/Feature/Fast.mdwn 30efd1cd6f42c4b0580efc513d21463a04b0ae79 @@ -1,10 +1,12 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The VCS should be fast, especially for common operations. -= Partially Supported = +# Partially Supported Monotone is fast for many operations, including most common ones in a workspace like `diff` and `status` and `commit`, but not universally so. Monotone's speed results are mixed, but improving rapidly. @@ -19,7 +21,7 @@ PerformanceWork is active and ongoing to PerformanceWork is active and ongoing to address these issues. Even for deep histories, common developer operations within a workspace are quite fast: usually the limiting factor is disk seek speed reading workspace files to check for changes. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Inodeprints Inodeprints] ============================================================ --- wiki/Feature/LightweightBranches.moin aad2b4d0e1090373a9a1ff2625a4ab051ca08f97 +++ wiki/Feature/LightweightBranches.mdwn d8ec536deeb0f29e7f83d8ce4791fe28ca0f0b78 @@ -1,18 +1,20 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Easy and cheap branching to allow parallel lines of development, and sophisticated history-aware merging for keeping branches in sync. -= Supported = +# Supported -Monotone's implementation of branches is ''extremely'' lightweight, and quite different to that in many other systems. +Monotone's implementation of branches is *extremely* lightweight, and quite different to that in many other systems. -Revisions can be in multiple branches (or none). Revisions can be added to branches long after they are first committed, perhaps after testing or code review to determine that they are suitable. Monotone separates completely the concept of a file's history (which is important for merging) from the concept of a branch (which is important for developers keeping track of the ''purpose'' of a particular development effort and view of the code). The BranchAnalogy describes the separation of these concepts. +Revisions can be in multiple branches (or none). Revisions can be added to branches long after they are first committed, perhaps after testing or code review to determine that they are suitable. Monotone separates completely the concept of a file's history (which is important for merging) from the concept of a branch (which is important for developers keeping track of the *purpose* of a particular development effort and view of the code). The BranchAnalogy describes the separation of these concepts. Monotone also has very robust and powerful merging capabilities (see FeatureMerging). -= Example Usage = +# Example Usage To commit some changes in a workspace to a new branch: {{{ @@ -20,7 +22,7 @@ To commit some changes in a workspace to $ mtn commit -b com.example.new-branch-name }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Branching-and-Merging Branching and Merging] ============================================================ --- wiki/Feature/LogReview.moin af13f2028f5066c6c465554cd4aca95cebdfc685 +++ wiki/Feature/LogReview.mdwn 47bdd8f9d66eafa14c1e8bdb822d7e3ac89369f9 @@ -1,20 +1,22 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The ability to check and enforce style or other formatting guidelines on log messages -= Supported = +# Supported Monotone supports the validate_commit_message hook, which is passed a user's intended commit message and details of the revision about to be committed. Hooks are implemented in lua, and can make arbitrary programmatic assessements of the log message to decide whether to accept or reject it. The default hook simply rejects empty messages. Note that these hooks are run on individual developer machines where the commits are done, offline. These developers could remove the hooks and commit noncompliant messages if they wanted (though of course those messages are signed so this misbehaviour is clearly their own responsibility). -= Example Usage = +# Example Usage See also: UsingCerts -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Hooks ValidationHooks] ============================================================ --- wiki/Feature/LogTemplates.moin 6b95d3adfff23d25a6dbae1febe95f054f80427b +++ wiki/Feature/LogTemplates.mdwn ff0d39741e3af68270d6f66c6dbe0020eb6d7ffc @@ -1,16 +1,18 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Commit log messages should start from a predefined template that prompts the developer to fill in certain information or follow certain conventions. -= Not Supported = +# Not Supported This is not presently supported, but would be simple to add - just nobody has gotten around to doing it yet. Like a number of other similar simple features and good ideas, this is one of the QuickieTasks that would be a great way for a new contributor to get used to the monotone code. It is possible to test the commit message for compliance to rules (see FeatureLogReview), and it would also be possible to implement this using hooks. One suggestion would be to use a hook on other commands (like update) to copy the template to `_MTN/log` if it is empty. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureLogTemplates VCSFeatureLogTemplates] ============================================================ --- wiki/Feature/MIMEtypes.moin cbefa97b30b877d7567618f7f1bc4b81ac464dee +++ wiki/Feature/MIMEtypes.mdwn 5eac1573212dcdd39fa83463c58ef13b3a347566 @@ -1,21 +1,23 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Annotating binary files in the repository with MIME-type information indicating how it should be handled. -= Supported = +# Supported There is no explicit support for MIME-type information specifically; monotone has no particular use for this information internally, and will simply store binary files like any other. However, this and any other similar information about files can be stored in a custom attr on the file, and any special file handling related to the mime type can be defined in an attr hook. -= Example Usage = +# Example Usage {{{ $ mtn attr set *.html MIMEType text/html $ mtn commit }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#File-Attributes File Attributes] ============================================================ --- wiki/Feature/Merging.moin 8c6ec6653a5f36e274b737147a00ee451e454c69 +++ wiki/Feature/Merging.mdwn 16325f0f42a0b0e20fe053f9dfefc3cdb84ae8e8 @@ -1,10 +1,12 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Automated and assisted merging of divergent revisions. -= Supported = +# Supported Monotone has very robust and powerful merging capabilities, which work based on the DAG history structure, independent of branches. These capabilities work regardless of how developers choose to use branches. @@ -14,7 +16,7 @@ Each of these commands will invoke exter Each of these commands will invoke external merge assistance tools (defined with merge hooks) to help developers choose changes and resolve conficts. -= Example Usage = +# Example Usage A very common developer loop: {{{ @@ -28,7 +30,7 @@ A very common developer loop: $ mtn update }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Branching-and-Merging Branching and Merging] ============================================================ --- wiki/Feature/Mirroring.moin baf14ce474fc0b2a7e726b4a16b22c90836ec5fa +++ wiki/Feature/Mirroring.mdwn e9fec1d6599111682bca5a82346d9957c16719fd @@ -1,17 +1,19 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Support replication or mirroring of the repository to remote sites, for load distribution and/or backup purposes. -= Supported = +# Supported This feature is fundamental to monotone, as a distributed VCS. There is essentially no other way of working, because every developer works with their own repository replica. Not all repositories are used for the same purpose, though. A project may choose to set up several servers, distributed geographically, to spread the load of software distribution and the risk of hardware or network failure. It is easy to set up automated replication between servers, or to rely on users to relay new revisions between servers. -= Example Usage = +# 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: {{{ @@ -24,7 +26,7 @@ These servers are inherently peers, ther These servers are inherently peers, there is no particular need for any of them to be considered the MasterRepository. As discussed in that page, there is no particular need to back up either of these servers, their content can be restored from the other server, or from developer's databases - anything in a server database will also exist in one or more other databases where it was originally committed, at least. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Network-Service-Revisited Network Service Revisited] ============================================================ --- wiki/Feature/NetworkSecurity.moin a6108cdc69b1566413971c22fefd6ad070b722ae +++ wiki/Feature/NetworkSecurity.mdwn d2d1cb04c0b62e3594ee5b8173c341f49f05eba9 @@ -1,22 +1,24 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Network operations should be secure. -= Supported = +# Supported Monotone's netsync protocol uses mutual authentication of client and server keys and has integrity protection, as do the signed revisions and file contents being transferred. It is recommended that servers use dedicated keys. -It does '''not''' inherently include confidentiality protection via native encryption, but this can be added via port forwarding through SSH, IPSec, or other suitable means. Netsync also supports a direct ssh transport where a user has personal databases on two machines and ssh accounts and access between them; this is not scalable to many users as accessing a database via `ssh://` locks it, while the same database can be accessed by many netsync users concurrently. +It does **not** inherently include confidentiality protection via native encryption, but this can be added via port forwarding through SSH, IPSec, or other suitable means. Netsync also supports a direct ssh transport where a user has personal databases on two machines and ssh accounts and access between them; this is not scalable to many users as accessing a database via `ssh://` locks it, while the same database can be accessed by many netsync users concurrently. If you have confidentiality concerns about your revision contents (because you are working on a sensitive project), you will also need to protect the distributed database and workspace contents on disk as well as in transit across the network and in their use with other development tools. Several of these aspects are platform dependent and outside of monotone's direct control, so each project should select measures appropriate to their needs. -= Example Usage = +# Example Usage -''todo'' +*todo* -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Basic-Network-Service Basic Network Service] ============================================================ --- wiki/Feature/Obliterate.moin 07da7a6da68dddc91f5a1be4c91699dfbaeb00f4 +++ wiki/Feature/Obliterate.mdwn 94388e7338b7d632fa402748e96105bbeaff001d @@ -1,20 +1,22 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description To completely remove content and history of something committed inappropriately when necessary. Note that this is not the same as just backing out bad changes, which should be recorded as normal history. This is to remove content that must be purged, perhaps because it is legally encumbered or otherwise inappropriate. It's not something that will happen often, but can be very important when needed. -= Partially Supported = +# Partially Supported -This is an especially challenging operation for monotone and any other distributed VCS, because of the replicated nature of the repository. It can be difficult to know where all the copies of the offending material may be, and even more difficult to exert control over all of those places. Ordinarily, this is a good thing: in monotone, it is and '''should''' be hard to remove history information by any kind of inadvertent command or accident or anything else other than a deliberate and organised effort. +This is an especially challenging operation for monotone and any other distributed VCS, because of the replicated nature of the repository. It can be difficult to know where all the copies of the offending material may be, and even more difficult to exert control over all of those places. Ordinarily, this is a good thing: in monotone, it is and **should** be hard to remove history information by any kind of inadvertent command or accident or anything else other than a deliberate and organised effort. -It is something that cannot be entirely addressed purely within software; consider the database on someone's backup CD or DVD as an example. This is therefore something that can only ''ever'' be partially supported by any distributed VCS application, and will require manual steps in accordance with the particular situation at hand. +It is something that cannot be entirely addressed purely within software; consider the database on someone's backup CD or DVD as an example. This is therefore something that can only *ever* be partially supported by any distributed VCS application, and will require manual steps in accordance with the particular situation at hand. The problem arises if the offending revisions and content have been `sync`ed to other databases and spread from there. Even if all those copies can't also be destroyed, they need to be prevented from replicating back into the cleaned-up databases. The potential for a feature to filter and reject known-bad incoming revisions from netsync has been discussed but not yet implemented. This may be enough that a project can remove and prevent redistribution of the offending content from their own servers. Future work on policy and trust distribution mechanisms may offer further capabilities in this regard. -= Example Usage = +# Example Usage Revisions can be removed from a local database, if they have no descendants: {{{ @@ -31,7 +33,7 @@ These steps will need to be taken on all 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. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureObliterate VCSFeatureObliterate] ============================================================ --- wiki/Feature/Offline.moin e1fbc090b60dd2e43fc9871ef70d7c230662445c +++ wiki/Feature/Offline.mdwn cf75aa0a5f61a7f29a62f527f5a0edf0b5f65093 @@ -1,19 +1,21 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The ability for developers to work offline, without access to a network repository, and still perform most or all useful VCS operations. -= Supported = +# Supported This is fundamental to monotone and fully supported. -The ''only'' operations that use the network are those that transfer revisions: `sync` and its one-way cousins `pull` and `push`. ''All'' other operations, including `commit` and `merge`, are distributed and occur locally offline. Developers can continue to work offline, publishing their work and learning of the work done by others with a quick `sync` whenever network access is available. +The *only* operations that use the network are those that transfer revisions: `sync` and its one-way cousins `pull` and `push`. *All* other operations, including `commit` and `merge`, are distributed and occur locally offline. Developers can continue to work offline, publishing their work and learning of the work done by others with a quick `sync` whenever network access is available. Indeed, reasonable portions of monotone's own development has been done offline, such as while travelling, often because working on other projects would have been harder at the time. Even these operations do not necessarily need to use the network: revisions can be shared between developers by syncing with a database on a removable flash widget that moves between disconnected machines, as one example. -= Example Usage = +# Example Usage All of the following (and many other things besides) work entirely offline: {{{ @@ -24,7 +26,7 @@ All of the following (and many other thi $ mtn commit }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Storage-and-workflow Storage and workflow] ============================================================ --- wiki/Feature/Portable.moin 58dc1094939cdd44ebb9fedc8c5d9fbb04458399 +++ wiki/Feature/Portable.mdwn 8e869a5838741208c3ab03e3eacdc503f3113ae6 @@ -1,14 +1,16 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The VCS tools should be portable to run on many kinds of development platform. -= Supported = +# Supported Monotone is implemented in C++, and compiles and runs on all sorts of different kinds of Unix systems and Windows. It is packaged in a number of linux distribution and packaging systems, as well as NetBSD pkgsrc which itself supports a number of different systems: see BuildingViaPkgsrc. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Rename.moin 2c29e9571dc1e97d4794a9539a1d142ab33c0834 +++ wiki/Feature/Rename.mdwn 6c7fd056de73915f8df7438bfcdab69cf6ceee06 @@ -1,14 +1,16 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Rename files and directories without losing history or breaking future merges. -= Supported = +# Supported The `rename` command (also aliased as `mv`) will allow files and directories to be renamed without breaking forwards or backwards history. These changes can be committed along with content changes as a single revision. Commands that use the history, including `log` and `merge` and `annotate`, will follow files through arbitrary renames. Two revisions that rename the same original file to different names, or that rename two different files to the same new name, will (correctly) cause a conflict will need to be resolved before they can be merged. -= Example Usage = +# Example Usage To rename a file: {{{ @@ -19,7 +21,7 @@ To rename a file: ''(-e executes the change in the workspace filesystem as well as in monotone's history)'' -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#SectionName Manual Section Name] ============================================================ --- wiki/Feature/RobustRepository.moin a8f91a82b8581a5310e3e437d19a0b131afd9b36 +++ wiki/Feature/RobustRepository.mdwn 95cf48aeded395db8848c15993dcf85cafbd0f46 @@ -1,10 +1,12 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description The repository storage format should be robust and resilient to problems caused by crashes, full filesystems, etc. -= Supported = +# Supported Monotone's repository is stored in an ACID-compliant [http://www.sqlite.org SQLite] database file. All monotone operations that write to the database occur inside transactions, and so either happen completely or not at all. This includes not only normal VCS operations, but also administrative actions such as database schema upgrades that may occur from time to time as monotone develops. @@ -16,11 +18,11 @@ See also: FeatureCompactRepository See also: FeatureCompactRepository -= Example Usage = +# Example Usage Interrupt or kill monotone during any operation. -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Database Database Commands] ============================================================ --- wiki/Feature/SignedRevisions.moin a4a5100a01dd26c8aa483a89a7fbfdb886eac4c3 +++ wiki/Feature/SignedRevisions.mdwn 39be6532825e0c03545be5263107e5c717ba10f0 @@ -1,16 +1,18 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Revisions and changes should be cryptographically signed to ensure historical integrity and detect accidental or malicious alteration. -= Supported = +# Supported This is a primary and fundamental component of monotone. Revisions are identified by the SHA-1 hash of their ancestry+content, and additional metadata about these revisions is attached using signed certs. -= Example Usage = +# Example Usage -'''' +** {{{ $ mtn ... @@ -18,7 +20,7 @@ This is a primary and fundamental compon $ mtn ... }}} -= Further Reference = +# Further Reference Manual and Tutorial Sections: * [http://venge.net/monotone/monotone.html#Certificates Certificates] ============================================================ --- wiki/Feature/Symlinks.moin 2a3964d71fbc071f92452d34365946fd56283c88 +++ wiki/Feature/Symlinks.mdwn eff0776f2e133f6b6869957af5d901cea120f2b3 @@ -1,18 +1,20 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Store Unix Symbolic Links as versionable objects in the repository, and recreate them on checkout/update. -= Partially Supported = +# Partially Supported Monotone ignores symlinks by default, but extensions to store these can be implemented using attrs and hooks. These are under active development and in use at the moment and may be integrated into a future release. -= Example Usage = +# Example Usage See UnixAttribsAndSymlinks -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureSymlinks VCSFeatureSymlinks] ============================================================ --- wiki/Feature/Template.mdwn 08af1f5d6ceaec78bd8456ae9b133ddd7b39dd78 +++ wiki/Feature/Template.mdwn 4de54aad3a1774b166e5ac7776cf060ee70531a6 @@ -1,31 +1,31 @@ -[[tag migration-wip]] +[[tag migration-done]] -''This page is a template for..'' +*This page is a template for..* This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description # -'''' +*A short description of the capability or feature and why you would want to use it* -= Supported/Not Supported/Partially Supported/etc.. = +# Supported/Not Supported/Partially Supported/etc.. -'''' +*A short description of monotone's capability. Make reference to commands and other wiki pages that might have further description. Mention the monotone version that made the most recent signifigant change to this feature, if possible. Try to avoid long discussion directly here, link to development pages instead* -= Example Usage = +# Example Usage -'''' +*If relevant, walk through a quite example of how to use the feature* -{{{ - $ mtn ... - - $ mtn ... -}}} + $ mtn ... + + $ mtn ... -= Further Reference = +# Further Reference Manual and Tutorial Sections: - * [http://venge.net/monotone/monotone.html#SectionName Manual Section Name] +* [Manual Section Name](http://venge.net/monotone/monotone.html#SectionName) + Features and Requirements in other evaluations: + +* FreeBSD [VCSFeatureBlah](http://wikitest.freebsd.org/VCSFeatureBlah) - * FreeBSD [http://wikitest.freebsd.org/VCSFeatureBlah VCSFeatureBlah] ============================================================ --- wiki/Feature/VendorBranches.moin f03506ca59fbef2f3df1f0fed561f86dd26fbe4a +++ wiki/Feature/VendorBranches.mdwn 784aad745e2bfce39b6786e3f8b55fa5c8332787 @@ -1,10 +1,12 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description Import external sources from third-party vendors, and allow tracking and sensible merging of local changes with future vendor releases. -= Supported = +# Supported Any branch can be used as a Vendor Branch. Unlike CVS, vendor branches are not treated specially in monotone. (This CVS feature with a single branch which behaves "magically" has now come to be seen fairly widely as a mistake.) @@ -12,11 +14,11 @@ There are two aspects to this requiremen * tracking "pristine" external sources in a separate branch * using the sources in such a branch as part of a larger derivative project -= Example Usage = +# Example Usage -''under construction'' The VendorBranchPattern page (will) contain detailed recommendations for BestPractices in how this should be done. +*under construction* The VendorBranchPattern page (will) contain detailed recommendations for BestPractices in how this should be done. -= Further Reference = +# Further Reference Features and Requirements in other evaluations: * FreeBSD [http://wikitest.freebsd.org/VCSFeatureVendorBranches VCSFeatureVendorBranches] ============================================================ --- wiki/Feature/WebInterface.moin 9157dd1e6ad73fddb4056fe1dc4e1af212c128fb +++ wiki/Feature/WebInterface.mdwn ea021a1a917c9a8e8b59fded3a64b796e5acd308 @@ -1,21 +1,23 @@ +[[tag migration-wip]] + This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. -= Description = +# Description A web-based interface should allow for easy browsing of sources, history, logs, diffs, etc. -= Supported = +# Supported There are a number of InterfacesFrontendsAndTools that work with monotone, including several web-based ones. Monotone's own sources can be browsed using [http://grahame.angrygoats.net/viewmtn.shtml ViewMTN], and there is also a [http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/ Trac plugin] under development. -= Example Usage = +# Example Usage * [http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone Recent monotone activity, via ViewMTN] * [http://viewmtn.angrygoats.net/headofbranch.psp?branch=net.venge.monotone Current monotone HEAD revision] * [http://trac.h975245.serverkompetenz.net/ Trac-monotone demonstration] * [http://cia.navi.cx/stats/project/monotone Recent monotone activity, via CIA] -= Further Reference = +# Further Reference Features and Requirements in other evaluations: ============================================================ --- wiki/FileSystemIssues.moin 8d73f3572a576b94a792214523e2ae55fd329fa9 +++ wiki/FileSystemIssues.mdwn f9d34b769014225c5eadde10398f3f54a2b7fd9c @@ -1,5 +1,7 @@ -= File System Issues in Monotone = +[[tag migration-wip]] +# File System Issues in Monotone + About: Encoding, platform independency and case of filenames (codepages and unicode)[[BR]] Related: CaseInsensitiveFilesystems @@ -9,7 +11,7 @@ directoryname and filename can be used s directoryname and filename can be used synonymous. I hope I always used the word filename. -== The facts == +## The facts 1. Monotones copy libidn's stringprep does not work on mingw (win32). Calling "mtn löl" causes following output: [[BR]][[BR]] ?: error: failed to convert string from ASCII to UTF-8: 'l?l'[[BR]][[BR]] a. There is a quick fix for that: call "chcp" get your current codepage and set it for example: "set CHARSET=CP850". @@ -26,11 +28,11 @@ Now for the speculation... Now for the speculation... -== The speculations == +## The speculations This is a special problem, which probably only cross-platform SCM tools have. Even for tools like rsync this is not such a big problem, since the synced filename is possibly crap, but at least the contents are copied. And copying back will probably correct the filename again. But SCM Tools have to track these filenames on different platforms and file systems. Inconsistency will lead to errors in deltas, in merging... -=== File systems === +### File systems Most POSIX file sytems are transparent. They just accept the kind of encoding the user has set. @@ -56,9 +58,9 @@ Microsoft recommends to use the wide ver The GetACP() Page states: The ANSI code pages can be different on different computers, or can be changed for a single computer, leading to data corruption. For the most consistent results, applications should use Unicode UTF-8 (code page 65001) or UTF-16 when possible. -''But it does not state how you achieve that, since there is no SetACP(). So I think using the wide version of the functions should be save.'' +*But it does not state how you achieve that, since there is no SetACP(). So I think using the wide version of the functions should be save.* -'''Addition''': wilx found the setlocale() function, which will change the output of ANSI versions of function in the C Standard Library: [http://msdn2.microsoft.com/en-us/library/x99tb11d(VS.80).aspx] +**Addition**: wilx found the setlocale() function, which will change the output of ANSI versions of function in the C Standard Library: [http://msdn2.microsoft.com/en-us/library/x99tb11d(VS.80).aspx] * http://msdn2.microsoft.com/en-us/library/ms776442.aspx * http://en.wikipedia.org/wiki/UTF-16 @@ -152,7 +154,7 @@ Alternative solutions for case-insensiti Alternative solutions for case-insensitive FS are in CaseInsensitiveFilesystems, but I don't think they are conservative enough, on the other hand, if we really are going to only support the common subset, we need to implement "The very restrictive solution", which isn't nice, too. I'm glad I don't have to decide, but can just point out ideas. -'''Important:''' This list is not thought as ALL OR NOTHING. Only the solutions that make sense for someone who knows the internals of monotone better than I do should be implemented. AND there are certainly variants of these solutions and some of them might make more sense. +**Important:** This list is not thought as ALL OR NOTHING. Only the solutions that make sense for someone who knows the internals of monotone better than I do should be implemented. AND there are certainly variants of these solutions and some of them might make more sense. A variant to 12.: Checkout/update new filenames that can't be converted to local locale or can't be written with a automatically chosen filename. Write a message to the user with the orginal and the automatic filename and tell him he should use "mtn rename" to set useful name. So checkout/update will not fail. @@ -178,13 +180,13 @@ Wrong guess! How should it fix something that seems not fixable. -=== The terminal/console === +### The terminal/console Well, here most problems are solved by locales and the libidn. Except that it doesn't work on windows. Which can hopefully be solved by updating libidn or hacking the copy of libidn using GetACP(). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_21bk.asp -== About UTF-8 normalization == +## About UTF-8 normalization There are two commonly used normalizations of UTF-8: @@ -197,16 +199,16 @@ Which is NOT totally true. There are cha Which is NOT totally true. There are characters that don't have a precomposed form, so these will exist in NFC as decomposed form. (http://www.unicode.org/unicode/reports/tr15/) -=== Example === +### Example * precomposed is U+00[the latin-1 character] -> Á is U+00C1. * decomposed is U+00[base ASCII char] U+[combining ACCENT char] -> Á is U+0041 U+0301. -== What to do at the moment? == +## What to do at the moment? I use this script (http://fangorn.ch/n/blog/2007/01/20/isnotasciipl/) to check that all filenames are ASCII before I do a "mtn add -R". -== Pages == +## Pages * http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_21bk.asp * http://msdn2.microsoft.com/en-us/library/ms776442.aspx ============================================================ --- wiki/ForSide.moin e919705b36da5a0e07b8879015d678ae520188f2 +++ wiki/ForSide.mdwn 49224ef964b59238b37bfd0d54e05684efd0356a @@ -1,3 +1,5 @@ +[[tag migration-wip]] + ## Please edit system and help pages ONLY in the moinmaster wiki! For more ## information, please see MoinMaster:MoinPagesEditorGroup. ##master-page:FrontPage @@ -6,7 +8,7 @@ #language da #pragma section-numbers off -= MoinMoin Wiki = +# MoinMoin Wiki Et WikiWikiWeb er et kollaborativt hypertekst miljø, hvor styrken ligger i enkel adgang til og redigering af information. Denne wiki kan også linke til InterWiki rummet. ============================================================ --- wiki/FutureCryptography.moin c98562ff69dfb2f85d5f1bce968b570253e1262e +++ wiki/FutureCryptography.mdwn 1357ffb4527c1b5530654216fc0a533811a83c92 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + 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. -= Cryptographic hash function = +# Cryptographic hash function We must migrate to a new hash algorithm. @@ -18,7 +20,7 @@ If we assume that "second preimage" atta If we assume that "second preimage" attacks are infeasable but that collision generation might become feasable, things get interesting - attackers can't make new messages which match existing signatures, but they can probably cause ambiguous things to be signed. If you assume your attackers are not ahead of the curve on cryptanalysis, you could argue that signatures made before the attack are still valid, but those made after can't be trusted. Policy could explicitly bless all the pre-attack signatures but rule out future use of that hash function. -= Public-key signatures = +# Public-key signatures As well as the hash function change, two other changes will impact on public key signatures: @@ -34,7 +36,7 @@ We can reduce the computational burden o * A "math cache" in the database which records simply "this hash has been signed by this principal" so we don't have to do PK verification more than once per cert. * Cert chaining - each cert should have a field to name a hash of another cert as valid. Contributors would thus chain together all the certs they sign in each branch. Though each cert should be separately signed, you could verify all of a key's certs in a branch with a single PK operation. Thus you'd end up doing one PK operation per netsync per branch - very fast. We shouldn't use this chaining for any purpose besides the optimization described here. -== Signature standards == +## Signature standards Monotone currently supports only one kind of signature: RSA-SHA1-EMSA3. This doesn't have a lot to recommend it in and of itself. It's an old standard that doesn't have a security reduction from the RSA problem, so it might be broken even if RSA itself is secure. And RSA doesn't have anything inherent to recommend it over Rabin-Williams, which is faster and has a reduction from factoring. @@ -46,6 +48,6 @@ Obviously we'd like to use something sta Obviously we'd like to use something standard, but the world of standards is AFAICT in a difficult state at the moment - many of the standards we'd like to use have not caught up with SHA-256. In particular DSA and ECDSA are still bound to SHA-1. -= Netsync = +# Netsync Netsync's cryptography has both security and performance problems. Netsync is also quite unlike our use of cryptography elsewhere in Monotone. We should just bite the bullet and switch to SSL, while swallowing as little of X.509 as we can manage. ============================================================ --- wiki/Glossary.moin 2a6b1a782845668a8250f7d73e7871544d1b7fba +++ wiki/Glossary.mdwn 8169c5e85885d58a63b8a72075f53058d9994766 @@ -1,5 +1,7 @@ -''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.'' +[[tag migration-wip]] +*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.* + [[Anchor(Cert)]] Certificate:: (Normally: "Cert".) A note made against a revision. Certificates are used internally by Monotone - for example, to represent branches and to store the ID of the person committing a change - but can also be added manually by users. @@ -19,7 +21,7 @@ Directed Graph:: A diagram made up of points connected by arrows. In discussions about Monotone, this is normally just a shorter way of saying [#DirectedAcyclicGraph Directed Acyclic Graph]. [[Anchor(DirectedAcyclicGraph)]] - Directed Acyclic Graph (D.A.G.):: A diagram made up of points connected by arrows, where no arrow can lead back to an earlier point; in other words, the arrows cannot form a loop. If you drew a map of Monotone revisions, connecting each revision to each of its children by an arrow, this is the sort of graph you would be drawing. This is sometimes called the ''Revision Graph''. + Directed Acyclic Graph (D.A.G.):: A diagram made up of points connected by arrows, where no arrow can lead back to an earlier point; in other words, the arrows cannot form a loop. If you drew a map of Monotone revisions, connecting each revision to each of its children by an arrow, this is the sort of graph you would be drawing. This is sometimes called the *Revision Graph*. [[Anchor(Manifest)]] Manifest:: Monotone's term for a snapshot of all the files in a working copy. ============================================================ --- wiki/HistoryBlueSky.moin 8755486b8b434b2ef10e8267edcf4b216f226b91 +++ wiki/HistoryBlueSky.mdwn 3a5e4b3e848dde314aead126826edb1ea5ac0946 @@ -1,12 +1,14 @@ +[[tag migration-wip]] + Space-age things that would be cool to support in our history representation (though not strictly necessary): -= Suturing = +# Suturing -'''Use case:''' Melding together trees that were separately imported. For instance, PeterSimons (used to?) use monotone to manage his [http://autoconf-archive.cryp.to/ unified autoconf archive] -- there are several sites that collect autoconf macros, and he imports each into a "vendor branch", and then merges them all on top of each other. As each site updates the various macros in random ways, one can continue to propagate them together. +**Use case:** Melding together trees that were separately imported. For instance, PeterSimons (used to?) use monotone to manage his [http://autoconf-archive.cryp.to/ unified autoconf archive] -- there are several sites that collect autoconf macros, and he imports each into a "vendor branch", and then merges them all on top of each other. As each site updates the various macros in random ways, one can continue to propagate them together. Should it be undoable? The operation is not simple "split", it is "split into this logical file that went into the suture and that logical file that went into the suture". Very similar issues here as are faced by revival. -== Merging == +## Merging Not clear how to textual merging -- using a naive weave merge, for instance, there are no benefits to suturing at the file level, you also have to suture at the line level in some more complex way. But, directory suturing may be possible now. @@ -16,15 +18,15 @@ If it is undoable, rather than irrevocab If it is undoable, rather than irrevocable, then we need some way to merge suture states. Not clear how to do this. Random idea: model each pair-wise potential suture as a boolean, false means not currently sutured, true means currently sutured. Scalar merge these booleans. Problem: suturing is actually about the transitive closure of such pair-wise relations... -= File/directory revival = +# File/directory revival Important for reversion, undoing changes of all kinds -'''Use case:''' accidentally deleted something on a branch, need to revive it so future merges work right +**Use case:** accidentally deleted something on a branch, need to revive it so future merges work right -'''Use case (same as above, really):''' merged from a vendor branch, pruned parts that don't need. Later start needing them again; need to revive. +**Use case (same as above, really):** merged from a vendor branch, pruned parts that don't need. Later start needing them again; need to revive. -'''Use case:''' Allow propagating changes in *both* directions across a merge_into_dir. +**Use case:** Allow propagating changes in *both* directions across a merge_into_dir. * merge branch A into directory subdir/ in branch B * propagate A -> B to keep B up-to-date * edit something under subdir/ in B, and decide that it needs to be propagated upstream @@ -37,11 +39,11 @@ This should allow similar behavior to ne This should allow similar behavior to nested CVS checkouts as requested in [https://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=13409 Bug 13409] (although it'd be branch-wide instead of just a specific workspace). -== Merging == +## Merging Treat life as a scalar boolean, merge like any other scalr. -== Problems == +## Problems How do we specify what entity is being revived? @@ -51,12 +53,12 @@ May interact with content merging (becau May interact with content merging (because in weave merges for example, need to figure out how lines of new version correspond to lines in all "leaf" versions) -= Splitting = +# Splitting The conceptual inverse of suturing (though not, as noted above, the actual literal inverse). This is more like "copy" -- the inverse of a copy is a suture. Copies have all sorts of weird properties. You have to ask whether they are asymmetrical, for instance. -'''Use case:''' I want to add a new gcc backend. However, I find the prospect of writing such a thing from scratch terrifying, so I copy another backend and then modify it. I consider it kind of nice that things like "annotate" work smoothly across the copy (though there is some debate about this, because the guys who wrote the brand-X backend have no real desire to be hassled about the new brand-Y backend). As for merging, the brand-X guys should not be hassled about my changes. However, I may wish to merge in changes made to the brand-X backend. +**Use case:** I want to add a new gcc backend. However, I find the prospect of writing such a thing from scratch terrifying, so I copy another backend and then modify it. I consider it kind of nice that things like "annotate" work smoothly across the copy (though there is some debate about this, because the guys who wrote the brand-X backend have no real desire to be hassled about the new brand-Y backend). As for merging, the brand-X guys should not be hassled about my changes. However, I may wish to merge in changes made to the brand-X backend. +**Use case:** I'm refactoring, and I split one file into two parts. I'd like "annotate" etc. to follow the history in both directions. I'd also like edits to the pre-split file to be automatically applied to the post-splits files when I merge. -'''Use case:''' I'm refactoring, and I split one file into two parts. I'd like "annotate" etc. to follow the history in both directions. I'd also like edits to the pre-split file to be automatically applied to the post-splits files when I merge. ============================================================ --- wiki/Hosting.moin f13962875f0a802cf96b0190b44fba8db85f78d0 +++ wiki/Hosting.mdwn ab94b4fbf8ced47002785e3ab1cca6c0af890454 @@ -1,5 +1,7 @@ +[[tag migration-wip]] + 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?). If those two options don't work for you, here are some other options to consider: - * http://mtn-host.prjek.net provides '''free public monotone hosting''', with an easy-to-use web management interface. + * http://mtn-host.prjek.net provides **free public monotone hosting**, with an easy-to-use web management interface. * Virtual servers quite capable of running monotone are easily available in the $15-20/month USD range -- for example, [http://prgmr.com/xen/ here], [http://www.tektonic.net/vds.php?op=budget_plans here], [http://www.budgetdedicated.com/ here], or [http://www.slicehost.com/ here] (we have not used any of these services, and this is not a particular recommendation -- if you have recommendations, by all means add them here). If going this route, note that the monotone server can be a bit cpu and memory hungry -- we're working on reducing this, but in the mean time, you probably don't want the very smallest servers available. ============================================================ --- wiki/HugoMills.moin 505ee089bf7588807478d05b5e3daea0b28ceab4 +++ wiki/HugoMills.mdwn 8b3526ec529983a4ea155558039e70b7fd34807e @@ -1,6 +1,8 @@ +[[tag migration-wip]] + #format wiki #language en -== Your Name == +## Your Name Email: [[MailTo(hugoATcarfaxDOTorgDOTuk)]] ============================================================ --- wiki/I18nL10n.moin 68d2b64f1651c8e1036990aecaaf2b3fc361dcd1 +++ wiki/I18nL10n.mdwn fcf0b74f76b8f4650f020908d54ad1a442400498 @@ -1,33 +1,35 @@ +[[tag migration-wip]] + i18n and l10n are non-trivial; more so for monotone than for most apps. -= Character sets = +# Character sets Firstly, we have to deal with at least 3 logically distinct charsets * the user's display/entry charset * the user's filesystem charset * utf8, for our internal storage -On most POSIX systems, the user's display/entry charset and the user's filesystem's charset are identical. On OS X, the filesystem charset is always unicode (though this is very poorly documented, so I'm just assuming it's utf8), and the user's display/entry charset ''may'' differ -- though I do not know if it ever does in practice. I don't know how things work on Win32, but I've heard that it's as bad as you might fear. +On most POSIX systems, the user's display/entry charset and the user's filesystem's charset are identical. On OS X, the filesystem charset is always unicode (though this is very poorly documented, so I'm just assuming it's utf8), and the user's display/entry charset *may* differ -- though I do not know if it ever does in practice. I don't know how things work on Win32, but I've heard that it's as bad as you might fear. -To make this more interesting, `gettext` returns strings in the user's display/entry charset. While technically you ''can'' tell `gettext` to instead return strings in utf8 (see `bind_textdomain_codeset`) -- perhaps because you think this will let you use a simple strategy, where internal data is always utf8 and you convert when talking to the outside world -- this runs into some issues in practice. In particular, `strerror` will continue to return errors in the user's charset (you can work around this by converting back manually; glib's `g_strerror` does this), popt will continue to use the local charset, and for extra fun, if a charset conversion error occurs, we have no way to report it, because we cannot print to the terminal without doing charset conversion. I tried doing this once and gave up -- if anyone wants to try again, the code around 2561d8175fafe1ce3718f1eb71112012892c5d21 will be useful. +To make this more interesting, `gettext` returns strings in the user's display/entry charset. While technically you *can* tell `gettext` to instead return strings in utf8 (see `bind_textdomain_codeset`) -- perhaps because you think this will let you use a simple strategy, where internal data is always utf8 and you convert when talking to the outside world -- this runs into some issues in practice. In particular, `strerror` will continue to return errors in the user's charset (you can work around this by converting back manually; glib's `g_strerror` does this), popt will continue to use the local charset, and for extra fun, if a charset conversion error occurs, we have no way to report it, because we cannot print to the terminal without doing charset conversion. I tried doing this once and gave up -- if anyone wants to try again, the code around 2561d8175fafe1ce3718f1eb71112012892c5d21 will be useful. The net result is that one needs to keep track, for basically every string in the system, which of the above charsets it is in, and do conversions appropriately. The best way to do this, obviously, is with the type system; we have a few vocab.cc types for this, but they are not used systematically. Much more work is needed; for instance, a real solution probably includes a modified formatter object that knows how to do charset conversion when doing %s replacement, and refuses to accept bare std::string's. -= Bugs = +# Bugs There are a bunch of places where we do not do proper conversion. Pretty much every F() call is suspect, but there are some particular places marked in the source with BUG, where njs happened to notice things while he was going through. Here are some more notable ones: -== Filesystem reading == +## Filesystem reading The tree walker does not convert from the filesystem charset to utf8, but it should. -== Data validation == +## Data validation /!\ `file_path`'s verifier should validate that it is handling valid utf8. We do not currently do this. I don't know if we make sure that changelog comments are appropriately converted. We may not. -== Display == +## Display There are various places -- commands.cc's lining up of commands, tickers lining up numbers with labels, tickers truncating themselves at the edge of the terminal to avoid staircasing, etc. -- where we need to know the display width of characters. @@ -35,11 +37,11 @@ I believe that the UNIX98 functions `wcw I believe that the UNIX98 functions `wcwidth`, `wcswidth`, and ilk, know how to deal with this. They are not necessarily available everywhere. Right now, we simply use a few lines of direct coding to count up utf8 characters, which is wrong even if we are dealing with utf8, and we probably can't count on that anyway. -== stringprep/idna/... == +## stringprep/idna/... We should probably audit everything dealing with stringprep/idna/etc. For instance, there is wackiness in handling i18n'ed key names, because email addresses have hostnames in them and i18n hostnames are wacky. -== Composition/decomposition == +## Composition/decomposition It is possible that there are filesystems which somehow normalize unicode strings. (E.g., [http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties HFS+ on OS X] probably does.) These raise issues similar to CaseInsensitiveFilesystems, i.e., any form of normalization can cause paths that looked different on one system to look the same on another. In fact, [http://svn.haxx.se/users/archive-2005-12/0381.shtml SVN has encountered this issue in practice]. @@ -50,6 +52,6 @@ The Unicode Consortium has an article on The Unicode Consortium has an article on [http://www.unicode.org/unicode/reports/tr15/index.html normalization forms] and a somewhat related article on [http://www.unicode.org/reports/tr36/ security considerations]. -= File content = +# File content The current system for converting charsets of versioned files, which is hook-based, is not so great. We should probably do something involving attrs instead. ============================================================ --- wiki/IPv6.moin 5c8384ba7aecb04feff53eb8ea9791b14bfadd61 +++ wiki/IPv6.mdwn 48a6666b21c8508128dc100665415a0d50bc1e59 @@ -1,6 +1,8 @@ +[[tag migration-wip]] + IPv6 is a bit tricky. -= Known problems = +# Known problems If a system does not have IPv6 support, then the default attempt to bind to all interfaces fails. ============================================================ --- wiki/InterfacesFrontendsAndTools.moin 9d842ffbb7c7c1a76eba9a74436614bc7fb392fc +++ wiki/InterfacesFrontendsAndTools.mdwn b65d58e509145238f09d29dc6a4e13b54e7ef2f4 @@ -1,75 +1,77 @@ -= Other programs that work with monotone -- interfaces, frontends and tools = +[[tag migration-wip]] -== interfaces and tools == +# Other programs that work with monotone -- interfaces, frontends and tools - * '''[http://oandrieu.nerim.net/monotone-viz/ monotone-viz]''': [http://gtk.org GTK+] app for browsing and visualizing history +## interfaces and tools + + * **[http://oandrieu.nerim.net/monotone-viz/ monotone-viz]**: [http://gtk.org GTK+] app for browsing and visualizing history * Emacs integration: - * '''monotone.el''': In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/branch/head/file/net.venge.monotone/contrib/monotone.el Latest version] (via viewmtn). + * **monotone.el**: In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/branch/head/file/net.venge.monotone/contrib/monotone.el Latest version] (via viewmtn). * [http://download.gna.org/dvc/ DVC] (see also [http://gna.org/projects/dvc DVC]) is a project to create a generic library for fancy Emacs interfaces to modern version control systems. DVC includes monotone support. - * '''[http://grahame.angrygoats.net/viewmtn.shtml viewmtn]''': a web interface to a monotone repository. + * **[http://grahame.angrygoats.net/viewmtn.shtml viewmtn]**: a web interface to a monotone repository. * As noted below, development of a trac plugin is ongoing: [http://tracmtn.1erlei.de/ TracMtn]. - * '''[http://mtn-host.prjek.net/projects/mtsh/ mtsh]''': GTK+ wrapper for monotone focusing on working copy operations -- add, drop, revert, rename, commit, update, diff, and browsing. Has a mechanism for per-file commit comments. ''(This is a bit old and very much unmaintained.)'' - * '''Usher''': A server manager that can be used to serve several projects on the same IP/port, starting and stopping servers as needed. In branch `net.venge.monotone.contrib.usher`. - * '''[http://meld.sf.net meld]''': a general diff, merge, and history browsing tool written in [http://python.org Python] for [http://gnome.org Gnome]. Has monotone support since 1.1.3. - * '''shell completion''': monotone ships with completion scripts for both bash and zsh, in the `contrib/` directory of monotone's source tree. Latest versions for [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone.bash_completion bash] and [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone.zsh_completion zsh] (via viewmtn). - * "'''dumb server'''" support, for publishing repositories via ordinary ftp/http/sftp/local filesystem: in branch [http://viewmtn.angrygoats.net/branch/changes/net.venge.monotone.dumb]. - * '''[http://www.midwinter.com/~lch/programming/m7/ m7]''': Experimental drop-in command-line wrapper for monotone. Adds simple local version numbers (no longer using certs) and an enhanced annotate front-end. - * '''[http://www.highscore.de/monotree/ monotree]''': java app for browsing and visualizing history; more portable than monotone-viz. In branch `net.venge.monotone.contrib.monotree`. - * '''[http://rscm.rubyforge.org/classes/RSCM/Monotone.html RSCM::Monotone]''': a [http://www.ruby-lang.org/ Ruby] interface to monotone. - * '''monotone-import.pl''': A script to ease importing other people's source distributions into a monotone branch, useful for tracking "vendor branches" and the like. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone-import.pl Latest version] (via viewmtn). - * '''monotone-notify.pl''': A script to watch a monotone repository and, for example, send emails on commits. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone-notify.pl Latest version] (via viewmtn). - * '''ciabot_monotone.py''': A notification script for [http://cia.navi.cx CIA]. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/ciabot_monotone.py Latest version] (via viewmtn). - * Script for '''importing maildir-format mailboxes''' to monotone, for offline reading and syncing: [http://lists.gnu.org/archive/html/monotone-devel/2005-09/msg00234.html on the list] - * '''[http://www.wireshark.org Wireshark]''' (new fork) and '''[http://www.ethereal.com Ethereal]''' (original, possibly inactive branch): a fantastic network traffic analyzer, that has support for decoding monotone's 'netsync' protocol. - * '''[http://guitone.thomaskeller.biz guitone]''': A Qt-based, cross-platform frontend for monotone, in early stage [http://viewmtn.angrygoats.net/branch/head/browse/net.venge.monotone.guitone Latest version (via viewmtn)]. - * '''[http://aleph0.info/apso/ Apso]''': A system for encrypting version control system repositories/databases (currently a prototype; the first version control system supported is Monotone). - * '''[http://www.highscore.de/monotree/ Monotree]''': A .NET based viewer for monotone's database (does not require to have monotone installed as it loads monotone's database directly and creates a report). - * '''[http://ikiwiki.info/ Ikiwiki]''' is a wiki that can use a revision control system, and in particular [http://ikiwiki.info/rcs/monotone/ monotone], as a backend. As Monotone is distributed, Ikiwiki becomes distributed. Ikiwiki also has a bug tracking plugin that then allows distributed bug tracking. + * **[http://mtn-host.prjek.net/projects/mtsh/ mtsh]**: GTK+ wrapper for monotone focusing on working copy operations -- add, drop, revert, rename, commit, update, diff, and browsing. Has a mechanism for per-file commit comments. *(This is a bit old and very much unmaintained.)* + * **Usher**: A server manager that can be used to serve several projects on the same IP/port, starting and stopping servers as needed. In branch `net.venge.monotone.contrib.usher`. + * **[http://meld.sf.net meld]**: a general diff, merge, and history browsing tool written in [http://python.org Python] for [http://gnome.org Gnome]. Has monotone support since 1.1.3. + * **shell completion**: monotone ships with completion scripts for both bash and zsh, in the `contrib/` directory of monotone's source tree. Latest versions for [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone.bash_completion bash] and [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone.zsh_completion zsh] (via viewmtn). + * "**dumb server**" support, for publishing repositories via ordinary ftp/http/sftp/local filesystem: in branch [http://viewmtn.angrygoats.net/branch/changes/net.venge.monotone.dumb]. + * **[http://www.midwinter.com/~lch/programming/m7/ m7]**: Experimental drop-in command-line wrapper for monotone. Adds simple local version numbers (no longer using certs) and an enhanced annotate front-end. + * **[http://www.highscore.de/monotree/ monotree]**: java app for browsing and visualizing history; more portable than monotone-viz. In branch `net.venge.monotone.contrib.monotree`. + * **[http://rscm.rubyforge.org/classes/RSCM/Monotone.html RSCM::Monotone]**: a [http://www.ruby-lang.org/ Ruby] interface to monotone. + * **monotone-import.pl**: A script to ease importing other people's source distributions into a monotone branch, useful for tracking "vendor branches" and the like. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone-import.pl Latest version] (via viewmtn). + * **monotone-notify.pl**: A script to watch a monotone repository and, for example, send emails on commits. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/monotone-notify.pl Latest version] (via viewmtn). + * **ciabot_monotone.py**: A notification script for [http://cia.navi.cx CIA]. In `contrib/` directory of monotone's source tree. [http://viewmtn.angrygoats.net/fileinbranch.psp?branch=net.venge.monotone&path=contrib/ciabot_monotone.py Latest version] (via viewmtn). + * Script for **importing maildir-format mailboxes** to monotone, for offline reading and syncing: [http://lists.gnu.org/archive/html/monotone-devel/2005-09/msg00234.html on the list] + * **[http://www.wireshark.org Wireshark]** (new fork) and **[http://www.ethereal.com Ethereal]** (original, possibly inactive branch): a fantastic network traffic analyzer, that has support for decoding monotone's 'netsync' protocol. + * **[http://guitone.thomaskeller.biz guitone]**: A Qt-based, cross-platform frontend for monotone, in early stage [http://viewmtn.angrygoats.net/branch/head/browse/net.venge.monotone.guitone Latest version (via viewmtn)]. + * **[http://aleph0.info/apso/ Apso]**: A system for encrypting version control system repositories/databases (currently a prototype; the first version control system supported is Monotone). + * **[http://www.highscore.de/monotree/ Monotree]**: A .NET based viewer for monotone's database (does not require to have monotone installed as it loads monotone's database directly and creates a report). + * **[http://ikiwiki.info/ Ikiwiki]** is a wiki that can use a revision control system, and in particular [http://ikiwiki.info/rcs/monotone/ monotone], as a backend. As Monotone is distributed, Ikiwiki becomes distributed. Ikiwiki also has a bug tracking plugin that then allows distributed bug tracking. -== converting to monotone from other systems == +## converting to monotone from other systems CVS:: no external tool required or recommended; simply use monotone's `cvs_import` command. See ["MonotoneAndCVS"]. - Subversion, Darcs, many others:: '''[http://progetti.arstecnica.it/tailor Tailor]''' is an any-to-any version control system converter, with support for most free VCSes. Note that as of July 2007, histories are linearized on the timestamp (so don't expect it to losslessly convert between systems with DAG histories, like monotone/git/mercurial/bzr, for instance). + Subversion, Darcs, many others:: **[http://progetti.arstecnica.it/tailor Tailor]** is an any-to-any version control system converter, with support for most free VCSes. Note that as of July 2007, histories are linearized on the timestamp (so don't expect it to losslessly convert between systems with DAG histories, like monotone/git/mercurial/bzr, for instance). bitkeeper:: A patch and set of scripts for lossless BK->monotone conversion is available on the mailing list: http://lists.gnu.org/archive/html/monotone-devel/2006-01/msg00314.html -== Integrated development environments == +## Integrated development environments - * '''[http://pida.berlios.de/ PIDA]''': Integrated development environment supporting Monotone (among others) + * **[http://pida.berlios.de/ PIDA]**: Integrated development environment supporting Monotone (among others) -== merge tools == +## merge tools When you do a merge in monotone, and run into conflicts, it will automatically start up a nice graphical merger for you to resolve them in. These mergers (and possibly others) are supported out of the box. - * '''[http://kdiff3.sourceforge.net/ KDiff3]''': Supported on Unix, Windows, OS X. ('''recommended''') - * '''[http://furius.ca/xxdiff/ xxdiff]''': Supported on Unix, maybe OS X. ('''recommended''') - * '''[http://tortoisesvn.tigris.org/ TortoiseMerge]''': Supported on Windows. This is a stand-alone merge program that happens to be packaged with TortoiseSVN -- so you have to install the whole TortoiseSVN package, but you will only use TortoiseMerge. ('''recommended''') - * '''[http://www.gnu.org/software/emacs/emacs.html emacs]'''/'''[http://www.xemacs.org/ xemacs]''': via [http://www.delorie.com/gnu/docs/emacs/ediff.html Ediff]. Supported pretty much everywhere. - * '''[http://www.vim.org/ vim]''': via vimdiff. Supported pretty much everywhere. - * '''[http://meld.sourceforge.net/ meld]''': Supported on Unix (Gnome). + * **[http://kdiff3.sourceforge.net/ KDiff3]**: Supported on Unix, Windows, OS X. (**recommended**) + * **[http://furius.ca/xxdiff/ xxdiff]**: Supported on Unix, maybe OS X. (**recommended**) + * **[http://tortoisesvn.tigris.org/ TortoiseMerge]**: Supported on Windows. This is a stand-alone merge program that happens to be packaged with TortoiseSVN -- so you have to install the whole TortoiseSVN package, but you will only use TortoiseMerge. (**recommended**) + * **[http://www.gnu.org/software/emacs/emacs.html emacs]**/**[http://www.xemacs.org/ xemacs]**: via [http://www.delorie.com/gnu/docs/emacs/ediff.html Ediff]. Supported pretty much everywhere. + * **[http://www.vim.org/ vim]**: via vimdiff. Supported pretty much everywhere. + * **[http://meld.sourceforge.net/ meld]**: Supported on Unix (Gnome). * FileMerge.app: Part of the OS X Developer Tools package. Supported on OS X. [[Anchor(wishes)]] -= Other programs that *should* be taught to work with monotone, but haven't been = +# Other programs that *should* be taught to work with monotone, but haven't been * [http://trac.edgewall.com trac] is a popular integrated history browser/wiki/bug tracker, which has very recently grown a plugin interface that lets it work with VCSes besides subversion. The right place to start is probably the [http://projects.edgewall.com/trac/wiki/TracMercurial Mercurial plugin], since mercurial uses the basic monotone history model. (python) * Development of a trac plugin has already been started, see the [http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone.trac-plugin trac-plugin branch] or [http://tracmtn.1erlei.de/ TracMtn]. * "[http://repo.or.cz/w/hgct.git Commit Tool] or (h)gct is a GUI enabled commit tool...It allows the user to view diffs, select which files to committed (or ignored / reverted) write commit messages and perform the commit itself." (python) * [http://eclipse.org Eclipse] -- a well known, extremely pluggable IDE. Might be useful to look at the [http://eclipsedarcs.org/doku.php Darcs plugin] or [http://www.eclipse.org/community/team.php other] existing VCS plugins. (java) * [http://www.jetbrains.com IntelliJ IDEA] is a commercial java IDE with strong support for analysis and refactoring, and an open plugin API allowing integration of new version control systems. Derek Scherger [http://www.mail-archive.com/address@hidden/msg05443.html claims] to have fiddled with a monotone plugin. Someone on the [http://intellij.org IntelliJ Community Wiki] claimed to be developing a monotone plugin, but did not want to publish the source yet. - * "git-cvsserver": some crazy people have written a perl script that implements a usable subset of cvs's network protocol, backed against a git repo. the mapping is bidirectional, so people who like cvs, can do both checkout and ''commit'' using cvs, and it shows up in git. There is no reason this could not be taught to work against a monotone backend. "git clone http://mirrors.catalyst.net.nz/git/gitcvs.git/" + * "git-cvsserver": some crazy people have written a perl script that implements a usable subset of cvs's network protocol, backed against a git repo. the mapping is bidirectional, so people who like cvs, can do both checkout and *commit* using cvs, and it shows up in git. There is no reason this could not be taught to work against a monotone backend. "git clone http://mirrors.catalyst.net.nz/git/gitcvs.git/" * Xcode, the Apple Mac OS X IDE - * ''your request here'' + * *your request here* -= Other programs that don't exist at all, but if they did they would make using monotone just that much more awesome = +# Other programs that don't exist at all, but if they did they would make using monotone just that much more awesome * tools to manage code reviews, integration workflows, and such things * one possibly relevant thing: vim plugin for doing code reviews: http://www.vim.org/scripts/script.php?script_id=1563 * a cross-platform GUI monotone interface (probably using Qt, since that seems to be the best way to make sane cross-platform interfaces these days?) (GTKmm is really nice IMO, would be worth a look if someone went ahead on this) (both Qt and GTKmm add several megabtytes of bloat on OS X; try wxWindows or FLTK instead) * The work on a cross-platform GUI has already started, see http://guitone.thomaskeller.biz or mtn://venge.net/net.venge.monotone.guitone - * "Tortoise Monotone" -- a windows interface to monotone, integrated with the file explorer. This approach works ''very'' well for subversion... + * "Tortoise Monotone" -- a windows interface to monotone, integrated with the file explorer. This approach works *very* well for subversion... * `mtnpatch`, a small, standalone, slightly smarter version/wrapper of `patch(1)` that understands and can apply the additional cset operations (eg, `drop` and `rename`) listed in `mtn diff` comments. Useful for end-users tracking monotone sources without actually using monotone or a db. Bonus points for a `mtnfollow` that combines this patch tool with a web client to fetch diffs as needed from viewmtn, and keeps a `_MTN` directory up to date so its easy for a user to switch to using full monotone once they need it (eg, for local changes). * A Visual Studio plugin for Monotone. + * *your wished-for tool here* - * ''your wished-for tool here'' ============================================================ --- wiki/JackLloyd.moin 871bb9517356b15024d2d785a7cb2994d87cb9a2 +++ wiki/JackLloyd.mdwn 9654fecf50faebb942c1011b23edc95ae9d858a6 @@ -1,5 +1,7 @@ -== Jack Lloyd == +[[tag migration-wip]] +## Jack Lloyd + Wrote/maintains Botan. Used to work on OpenCM, which was somewhat Monotone-like. Email: [[MailTo(address@hidden)]] [[BR]] ============================================================ --- wiki/JustinPatrin.moin fc157c5c6a1ddddcdf5b3d116d1fa4ab6855dcf8 +++ wiki/JustinPatrin.mdwn 5bdcd4e7827982a4e5fd5d2eabb8b586239cc922 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + 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"]). For more info: ============================================================ --- wiki/KeystoreFiles.moin 9ca54de5971395feff06791195b07f3d82749565 +++ wiki/KeystoreFiles.mdwn c0d87637f7942b10723c16d4faa1abfb072a6b54 @@ -1,3 +1,5 @@ +[[tag migration-wip]] + I think the keystore, ~/.monotone/keys, could be more usable. (And this is an area where usability is important for security.) Problems: ============================================================ --- wiki/LineEndingMunging.moin 227520a6a479c07721cd8753ada4a2a806ae7c58 +++ wiki/LineEndingMunging.mdwn ec36aadccee4809958f37b1fd85c90c7dddade4d @@ -1,6 +1,8 @@ +[[tag migration-wip]] + 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? -The goal ''is not'' to come up with a perfect solution that can handle every single situation we can possibly conceive of, plus a large number we can't conceive of. The goal ''is'' to come up with the minimal solution that is correct and will not feel minimal to users. +The goal *is not* to come up with a perfect solution that can handle every single situation we can possibly conceive of, plus a large number we can't conceive of. The goal *is* to come up with the minimal solution that is correct and will not feel minimal to users. Discussion links: * http://thread.gmane.org/gmane.comp.version-control.monotone.devel/5881 @@ -9,15 +11,15 @@ Discussion links: * http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9231 * http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9304 -= In the Workspace = +# In the Workspace -== Current implementation == +## Current implementation We currently control this stuff with a hook. This is manifestly broken. It should be controlled per-file with attrs (I think the only reason it isn't is that attrs didn't exist back then). -== Other implementations == +## Other implementations -=== Subversion === +### Subversion Subversion has definitely put thought into their rules here. It's worth reading their [http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5 docs]. Basically, the rules are: * you have to opt-in to line end munging on a file-by-file basis @@ -26,22 +28,22 @@ Subversion has definitely put thought in * individual users can use the "autoprops" functionality to give a list of filename patterns and the eol-style that they want automatically applied to them * handling of edge cases is a bit weird -- their convert-to-