# # # patch "wiki/AutomateWishlist.mdwn" # from [15a0d58633f0262e20ccb6074239c87025d62b72] # to [bad8350781e1b4ff7614c8e5fedb4d9a82c2adb1] # # patch "wiki/BranchNamingConventions.mdwn" # from [c2360d3ff1a8d1e7bbb66a252406909ae1561833] # to [cf57a3f22cff7a3acc99d22398c09b9bf1938bdb] # # patch "wiki/BranchStatuses.mdwn" # from [b4b999e36dba5eecae6c3eab94de8f77fd7fa098] # to [67878e1a03d61b404d5cb92c804f1b5c37a288e7] # # patch "wiki/BuildingOnMac.mdwn" # from [71088dbe84d0c3322a515f5f15ffcc191e7bb73e] # to [8a31e9115514dbbe8f824c04df3a57a5fc0de28b] # # patch "wiki/BuildingOnSolaris.mdwn" # from [8b053776d47d3c83db21206930946c03f3e4d84c] # to [beb3578d0ee23092bdb70a06049e834afcce19ad] # # patch "wiki/BuildingOnWindows/VC8.mdwn" # from [7e634fdefe567977f98ab4061277db135bc1267b] # to [8819ee69771b91791e4197e629f3583b2fe7f4f9] # # patch "wiki/BuildingOnWindows/VisualC8.mdwn" # from [94783d10895d7d5232e0dcc462fe05abc2cf0ef1] # to [1a834e5b700ecd717828d5f016a6d7f834ce38f5] # # patch "wiki/BuildingViaPkgsrc.mdwn" # from [43366b5bde7c373eebee6c4d6ccd223b346de44f] # to [88942bfa371331eb53b779f151308037253e18dc] # # patch "wiki/CaseInsensitiveFilesystems.mdwn" # from [bd8916f43ca6e124bcf0ea3468806f0519b98add] # to [79646d133dfe5895498d5c0f91f14d1cb9bc3193] # # patch "wiki/CertCleanup.mdwn" # from [35d1c167e8b838597c2664e20f4fe8f5e986b231] # to [b98d0f049ab845bf865ddfa6f54e9b9635c6eb3f] # # patch "wiki/CvsImport.mdwn" # from [4fc4948dfc4c34041b31705275aa84f8320a14e9] # to [ef2d8c06ec67e31752a19c9a377a705394ee2c4d] # # patch "wiki/CvsSync.mdwn" # from [617f0bc498807610e0f7543bd6b8af0218728690] # to [4bda33be56d36b2dba1dd9ba3107100fa693f692] # # patch "wiki/CvsSync3.mdwn" # from [95c054e3e073c9d6347ad1006e433950bbe6e051] # to [693d7a2c5c75a849a3195880ee732cfb1739975c] # # patch "wiki/DatabaseLocking.mdwn" # from [8db279febdc86dca598a5a0346708c93052f9767] # to [840b19f235d0cba2303bab02ac336070ece0bf3b] # # patch "wiki/DeltaStorageStrategies.mdwn" # from [c26eaa90d7afa2472b6857116907ca3c3b18186e] # to [9aeef3ce1d8016fba4407bd286f6cc7d6ffb191a] # # patch "wiki/Feature/AccessControl.mdwn" # from [9a980522aa353e2bf88be5142809bf9cf58c464c] # to [fd35de82b389278ed8efaf000258678216bcb5c4] # # patch "wiki/Feature/AtomicCommit.mdwn" # from [29c3d2e76767abc306f1d60675c43d6da45d010c] # to [62cbb1633b28a91f02d70fc6d57d88d4f88053f1] # # patch "wiki/Feature/BuildIntegration.mdwn" # from [7cf28bf652e834abd5ad675cee39c066bce70fc8] # to [34c48ffeae8871727704d52876d5f142ac3297f1] # # patch "wiki/Feature/CVSExport.mdwn" # from [556a28b5c3d69f1d78d5c85efd1c9524b37b0869] # to [0ee0c4d5bd1c11d140fdd94ac78f2bc8af763d83] # # patch "wiki/Feature/CVSImport.mdwn" # from [6ab438123ca3a3e8ce797e9980cad6a67a2e48e5] # to [1ebd307f9eafad6cd3d1bf1f81bb32f033a60e24] # # patch "wiki/Feature/CommitMail.mdwn" # from [89a11b26992613af019bb03339f84e39d149cc3d] # to [41391462d99ab161d25619812ec51a0dc5651ce6] # # patch "wiki/Feature/CompactRepository.mdwn" # from [b48a906da90d11320ff31160b530d347cccf999c] # to [ae47674eb6960d3b72dbdff490e580ea202630c1] # # patch "wiki/Feature/EmbeddedIDs.mdwn" # from [38cfd1a7656f31457ed769d76b0b442a15baa8fb] # to [ef1123bdbf5da65e9d178ada663d70c0b84b0519] # # patch "wiki/Feature/Fast.mdwn" # from [250564ec5967e68a77cc0594d918f5a03fa7bf08] # to [f5ca9c5143b32c6816091d0be9bf1ebf75cce80c] # # patch "wiki/Feature/LightweightBranches.mdwn" # from [8e9b5849c95877a39d242f75bbb4daa9052ffb38] # to [113eaacc5fdd34c6330a8b4aa2dec2280ccc1d99] # # patch "wiki/Feature/LogReview.mdwn" # from [7b828c6c426ed291483945466cc788939b6ed374] # to [912ff658418d96d163c6a900731a368318b014d9] # # patch "wiki/Feature/LogTemplates.mdwn" # from [9294afc331b443216e9b06044754fa166d9bca56] # to [ac6cf94eb237a6feba601581e4a5240122907f6c] # # patch "wiki/Feature/MIMEtypes.mdwn" # from [1c93be76be7daa2781de294197237b2df440da32] # to [2689db6ba3008991214115f9644d5873d476a864] # # patch "wiki/Feature/Merging.mdwn" # from [3e6ad644cd409923ff27f7feca34170660ba6b98] # to [64d10b953c8de7c089998d8adda7794d7790fa0a] # # patch "wiki/Feature/Mirroring.mdwn" # from [ccf230c59e54ac08d5bea1085c505eef2ad04cb5] # to [1f8f6f3389430038e71ea158bfd90288e6311520] # # patch "wiki/Feature/NetworkSecurity.mdwn" # from [248ae3673807f8fad3eeb1a770aef7a8063bc903] # to [594d7d68bf4ce54ccf7172a794ea5a052b833458] # # patch "wiki/Feature/Obliterate.mdwn" # from [09055fc196d97ff69255eee7b48bc4f79d1b96d4] # to [132fb91bd79ee9985b57d55ab381d4f74e58cfac] # # patch "wiki/Feature/Offline.mdwn" # from [5b5d54da51bd028c17536df9be9a67b5d9c419df] # to [a6d9631c23fcc0c19b2cb202957e145c90544ddc] # # patch "wiki/Feature/Portable.mdwn" # from [06e63ae72cf35251468a0fb0e8fe6ba7915d044a] # to [e1d50d7cafdc0e0f89f0c78bce3629202afe47a9] # # patch "wiki/Feature/Rename.mdwn" # from [ed367b3a722dce6e2e7310318399292bdb3d1f0b] # to [1dfa84a25d2b4e378a8feab86291bcaaf0b9d37b] # # patch "wiki/Feature/RobustRepository.mdwn" # from [2d8363d5a47b997ab8427b41d5821886867b2856] # to [023e466445479a3ad974398c8605a12ff49e64a7] # # patch "wiki/Feature/SignedRevisions.mdwn" # from [6b25cd81b0a1430c6346e0aa09a5dcee09d517cc] # to [5e0760f7279533c01d8820e7eabc3ad215c7ca65] # # patch "wiki/Feature/Symlinks.mdwn" # from [9a6ba18289105562cb358341f9b5c2300196998f] # to [180df0600f90c1e0e095636fc8a08a6f42137e15] # # patch "wiki/Feature/VendorBranches.mdwn" # from [38defee445822db452e3987c83bf9733a7b46e57] # to [633542b06c347681cd56e9596837b82c85400887] # # patch "wiki/Feature/WebInterface.mdwn" # from [2bae6d76f591164fbc353bcf98bd67e1c6767ed5] # to [9294b668202df884f61bd3b643b20c9fad27bfdf] # # patch "wiki/FileSystemIssues.mdwn" # from [db6944e7812bc8ad2f409c47a9d10c7adc348244] # to [79508659be4b804c851f76b05b50e08fba178c5a] # # patch "wiki/FutureCryptography.mdwn" # from [6688192080db144f2b46722e211aee21d6805c87] # to [a42aa284e8285cc08978acbf3a6b0292519a1642] # # patch "wiki/Glossary.mdwn" # from [bbc004729dc2696bc995943758a90fca5b4137b4] # to [863cede393851dce1412cd5d13a3e8be54cc0f85] # # patch "wiki/HistoryBlueSky.mdwn" # from [a30f71e21b78ba477f75634e2d1183034a96e513] # to [031c440a8cdf8ca77dd4235d00bb78d15413ee83] # # patch "wiki/I18nL10n.mdwn" # from [d37ff66e52e735ebd40be12a9fa0f46f7933ff0e] # to [1632832ccfdd9a776c6af5860400bf2fb4193d09] # # patch "wiki/LineEndingMunging.mdwn" # from [0e365a92a60443c2f536f45dda152542472ecd8c] # to [d74d57c344ccca47471f7f10d8e55dc12825a3e1] # # patch "wiki/MagicSelectors.mdwn" # from [fba438d23bf42372454525cc649b23a32d915428] # to [20f0010b627dd161e6d9f41a2b6cfe9b943b6578] # # patch "wiki/MergeViaWorkingDir.mdwn" # from [9ec522b844ca7550240094d97708a2ae61dab95b] # to [c0ca2dbbb4ca56b2f5c644d29329f200b1bf5b41] # # patch "wiki/MonotoneAndCVS.mdwn" # from [d6209c3f5b6da5fe4203903121c8304f3bb4005c] # to [40e719d83f48c9f867b65e72f072d426018dee81] # # patch "wiki/MonotoneOnDebian.mdwn" # from [316868563d1e66015b5332bc11cfc6572bc89204] # to [e5923328247cbed0cfc7eb10bbc9d3269178b448] # # patch "wiki/MtnSummit/2007/LogisticsNA.mdwn" # from [079150c07efae87e1455cdd20e217e56ff2d6080] # to [8ebda54f2d0363a5de064dcd2b1b976bc13be903] # # patch "wiki/NonMergeConflicts.mdwn" # from [4a80a8af4461f7a28082d2f60ed0e20306f5a396] # to [11092391afbadd10224dface7b50b6811138afb9] # # patch "wiki/NotesOnTestingChangesetify.mdwn" # from [b2f737820424e8b0281cfda3fd47acb828cd6a6a] # to [360c2233b395292730f095ad1de8403287d1329d] # # patch "wiki/People/JackLloyd.mdwn" # from [036e54acee902b77709e28e75d8fa4cece0af467] # to [0536ccbe46fa7d823affe70bd886cc81b35e950e] # # patch "wiki/People/JustinPatrin.mdwn" # from [6dda38f33652fce1df493e5d5e8cbf09a1bd0ec5] # to [1b5461ef8cabf9c7c2d4ce00ffa690776ced252b] # # patch "wiki/People/MarkusSchiltknecht.mdwn" # from [e7af610cd03712930184610b9509e1ec2e36a046] # to [e106baca0cb562129738b51fb3396a4aca33d0af] # # patch "wiki/People/RichardLevitte.mdwn" # from [9b53e2e160ffd880a10671eea7e42342c1f2d25e] # to [d27520b1b855279a8ede6359d342778e6ada0298] # # patch "wiki/People/User:Metaeducation.mdwn" # from [e5e1184ce3c35a0f3db5135e4eafe89d158d7444] # to [c98624e401612fa72773eb4f5729c04ec8003e8a] # # patch "wiki/People.mdwn" # from [58876899a68913977e94b96b5b6992b6502e5475] # to [c09f37c644f055d62b7f9528fe7d737b61e21c0a] # # patch "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn" # from [f3a16d0e6c131eb5c0ed3faa8748727bfe226054] # to [195925cb3660849f40f64a4bc4c20735b27481a0] # # patch "wiki/PerformanceWork.mdwn" # from [324a5452ba0f3f4b204b0f95174ab988c3f81bca] # to [576077e6dc883da277d04218ea0952e0d2a6cd3f] # # patch "wiki/ReleaseBranchPattern.mdwn" # from [106f65ca6e1015c801912df7abfd294c00217b4a] # to [a0ca8cd2da2ba5a6225b56628164cbdebd662b35] # # patch "wiki/RevertUI.mdwn" # from [4324d897baf2c4a502cdc88309f531a57ef87d85] # to [4cc6065ac29149c10c25ca1e584104d080c2518a] # # patch "wiki/RostersTodo.mdwn" # from [bedeefc2da76f173cbbdc00bff1e4c46a5f7c79e] # to [a123e3feb2dad659d01eb758158d6e205b797c10] # # patch "wiki/SimplerIgnoreMechanism.mdwn" # from [d96b82bec9cc7525a07f5f2a9439dd0549202671] # to [a1cb5e03e5b348616ea479167714e3eb10e987f2] # # patch "wiki/SummerOfCode/2006.mdwn" # from [26c9465aa9acb5c1656d5ad260e24b2260751978] # to [a7d294e9ec6d3aebbe25421ca6b61a1e7fdc1c22] # # patch "wiki/SummerOfCode/2007/Ideas.mdwn" # from [64856bff66cddcd2c9d5eee8ad9e69cdba6a50fa] # to [420b0d4122e6423d940b7a1dc5057e4123db03bc] # # patch "wiki/TestHarnessIssues.mdwn" # from [cd9b9a7720dbdb6e0472f5168e60cbf25d9a0361] # to [153db3af1cd0c7e848debf5d930bda42c9e849a1] # # patch "wiki/Testimonials.mdwn" # from [9dfd1492338cfeb6ae268de8dde2a3cd02bc509c] # to [2a2c6e7300169f7cd5ee894560a3677e55c300ec] # # patch "wiki/TrustFoundations.mdwn" # from [3fb83b250596d7f4bc8517a43b7af17ea7d79e8e] # to [6f4b798cbcbac05d9cb61bd81e1a3df4126131d0] # # patch "wiki/UsingCerts.mdwn" # from [6d8aeb0974e5b0765949d7a482b21042dbf1b700] # to [9a6db131928b337840348625d6509b5ac0cff12e] # # patch "wiki/VendorBranchPattern.mdwn" # from [6621c77ce54e638e17fd2daf3fec439b2955b094] # to [0b0959b98e7b3642f2a176719f3b6ab9bc60bbd6] # # patch "wiki/VersionedPolicy/Archive.mdwn" # from [d7636e726c27da710afc84d1b8638d3ba09878d7] # to [27012092392a89a692c1aa870dd9fd7272071ae9] # # patch "wiki/VersionedPolicy/Comparison.mdwn" # from [b6a4c59f8ac0e36b6c7eea617ab2a631087b2297] # to [abc9be888d0073c990627167283b1c76a720de9f] # # patch "wiki/VersionedPolicy/Graydon.mdwn" # from [12ff51ff5b3eecc4383d96cb80bcbc1460caf55c] # to [22266864c4af8611753ebb7eccf7ecd9bab95a2a] # # patch "wiki/VersionedPolicy/SPKIWontWork.mdwn" # from [e89e46058e0872a83dfb44a8b28dbe40f63ebcbb] # to [8ac45302e880b2029559870b06dabcff1f382d2f] # # patch "wiki/Win32DeviceFiles.mdwn" # from [29e2e7aef2004f6248f86ffc9d17487d62f2f50f] # to [6476a4bc2bf326de2aabd22a6bd0eadccfdf8ce0] # # patch "wiki/ZeroConf.mdwn" # from [fd6b1785fe2b21e1e02a76996f6add0e2605004f] # to [0304edd116eae392b0de0970394a36e6ac7298f0] # # patch "wiki/ikiwiki_migration.mdwn" # from [a96c399e205ae0213082784115acaa97afe2102f] # to [a39c1ff455f434a55467d7d48caeeb397c4ff541] # ============================================================ --- wiki/AutomateWishlist.mdwn 15a0d58633f0262e20ccb6074239c87025d62b72 +++ wiki/AutomateWishlist.mdwn bad8350781e1b4ff7614c8e5fedb4d9a82c2adb1 @@ -24,7 +24,7 @@ Missing (but useful) functions for the a ## Extensions to support Graphical User Interfaces --- MarcelvanderBoom [[DateTime(2006-06-18T18:39:06Z)]] +-- [[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'. To me: @@ -34,7 +34,7 @@ are the same thing, just formatted diffe 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)]] +-- [[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). ============================================================ --- wiki/BranchNamingConventions.mdwn c2360d3ff1a8d1e7bbb66a252406909ae1561833 +++ wiki/BranchNamingConventions.mdwn cf57a3f22cff7a3acc99d22398c09b9bf1938bdb @@ -16,9 +16,9 @@ What we currently recommend. Many people 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"] +Supporters: ["arcatan"], [[ChadWalstrom]], ["gwk"] ## 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: @@ -36,30 +36,30 @@ EricAnderson: we use: "domain-name"/"pro EricAnderson: we use: "domain-name"/"project-name"/"project-branch" for global branches and "email-addr"/"project-name"/"project-branch" for personal branches. The standard for the mainline "project-branch" is just main. The only difference from the above examples is that we standardized on always having three levels in the names, which made things map slightly better onto how people coming from CVS seemed to think about branches. It has an interesting effect of if you do checkouts, they automatically show up in directories organized like the above, which is somewhat nice. However, this auto-directory effect probably wouldn't happen on Windows because the pathname separator on windows is \ not /. We haven't had any problem with people thinking they could browse these. - NathanielSmith: Since windows actually accepts both \ and / as directory separators, I think that probably would work after all. + [[NathanielSmith]]: Since windows actually accepts both \ and / as directory separators, I think that probably would work after all. -Supporters: MatthewNicholson, EricAnderson, DanielThompson +Supporters: [[MatthewNicholson]], [[EricAnderson]], [[DanielThompson]] ### 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. +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) +Supporters: [[RichardLevitte]] (obviously) ### Hierarchy by # -Example: `MyCompanyInc#project#branch`, `venge.net#monotone`, `net.venge#monotone#cvssync`, address@hidden +Example: `[[MyCompanyInc]]#project#branch`, `venge.net#monotone`, `net.venge#monotone#cvssync`, address@hidden The benefit of this format is that it doesn't really look like a URL and it doesn't require selector character change: `b:venge.net#monotone/a:address@hidden I don't believe this should have any impact on the filesystem checkout, given that the '#' is embedded within the name of the file and should be represented by all locales. Although the '#' is a meta character in POSIX shell for "comment", it does not get parsed as such if there is no space before it. -Supporters: ChadWalstrom +Supporters: [[ChadWalstrom]] ## Hierarchy by mixed separators @@ -79,7 +79,7 @@ DanielThompson: I would claim that addin DanielThompson: I would claim that adding a monotone-specific URL transport into the branch name is a bad idea. Supporting a mtn:// transport command line syntax sugaring for 'monotone pull' (or even 'monotone checkout') would be pleasant but integrating the transport type into the branch name would not assist with this and I would prefer the 'sorta URL style' to a strict URL. - 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. + [[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 @@ -136,10 +136,10 @@ Stick in your name and your opinion: 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. - * 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. + * [[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. + * [[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 [....] - * ExampleUser: I think [....] ============================================================ --- wiki/BranchStatuses.mdwn b4b999e36dba5eecae6c3eab94de8f77fd7fa098 +++ wiki/BranchStatuses.mdwn 67878e1a03d61b404d5cb92c804f1b5c37a288e7 @@ -1,10 +1,10 @@ Currently active development branches: [[!tag migration-auto]] Currently active development branches: # n.v.m.cvssync (outdated) -Contact: ChristofPetig +Contact: [[ChristofPetig]] Adds two-way syncing with (remote) CVS servers @@ -12,11 +12,11 @@ Open issues: the data structure (map) has difficulties and is inefficient for large (>1000 changesets) repositories; propagates gather too much changelog info; most problems arise when $Id$ tags get expanded differently; not yet reindented with GNU style. -See also CvsSyncHints. +See also [[CvsSyncHints]]. # n.v.m.cvssync.refactor -Contact: ChristofPetig +Contact: [[ChristofPetig]] A re-implementation of the cvssync architecture to be more modular, including a separate external process that interacts as a cvs client. @@ -39,7 +39,7 @@ What can be put into mainline: # n.v.m.git -Contact: PetrBaudis +Contact: [[PetrBaudis]] Adds two-way syncing with git repositories (unix only). @@ -47,15 +47,15 @@ Status: I'm not quite sure. Petr? (ms) # n.v.m.levitte.select-heads-of -Contact: RichardLevitte +Contact: [[RichardLevitte]] Adds an H: selector that runs erase_ancestors over the set determined by the rest of the selector. -Status: Blocked on figuring out the right way to integrate this cleanly with the rest of the selector functionality. See MagicSelectors. +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 -Contact: RichardLevitte +Contact: [[RichardLevitte]] Created: 2006-02-28 The purpose of this branch is to add a suite of tests for usher and make it a supported program instead of just a contributed thingy. @@ -64,7 +64,7 @@ Status: Work in progress # n.v.m.experiment.iface-refactor -Contact: NathanielSmith +Contact: [[NathanielSmith]] Some experimental UI and doc tweaks, in attempt to make things more streamlined and friendly to new users. @@ -76,7 +76,7 @@ Status: Work in progress. # n.v.m.annotate -Contact: EmileSnyder +Contact: [[EmileSnyder]] Staging branch for work on the "annotate" command. As of 2006-01-30, there is work in progress on implementing per-file-DAGs of the revision graph in the db so that you can walk just the portion of the full graph in which changes were made to a given file. @@ -88,7 +88,7 @@ Status: Work in progress. # n.v.m.debian -Contact: MatthewNicholson +Contact: [[MatthewNicholson]] This branch adds a monotone-server debian package and also includes some tweaks to the existing package like installing the bash completion files. This package handles creation and management of a monotone database and key pair and also includes scripts for stopping and starting the server. The package will also attempt to do db migrate and similar operations if necessary during upgrades. @@ -96,23 +96,23 @@ Status: Merged into mainline. # n.v.m.cvsimport-branch-reconstruction -Contact: MarkusSchiltknecht +Contact: [[MarkusSchiltknecht]] Features a graph-based cvs import algorithm, loosely based on the concepts of cvs2svn 2.0. -Status: Still close to completion :-) - for more details, see CvsImport +Status: Still close to completion :-) - for more details, see [[CvsImport]] # n.v.m.experiment.db-compaction -Contact: MarkusSchiltknecht +Contact: [[MarkusSchiltknecht]] -A branch for trying out things from DatabaseCompaction. It has been used for turning hex encoded hashes ones into binary data in the database. That change has landed on mainline on 31.03.2008. +A branch for trying out things from [[DatabaseCompaction]]. It has been used for turning hex encoded hashes ones into binary data in the database. That change has landed on mainline on 31.03.2008. Status: landed on mainline # n.v.m.experiment.encapsulation -Contact: ZackWeinberg +Contact: [[ZackWeinberg]] Removed the app_state from lots of places, instead we only pass down the required objects, which were formerly held in the app_state. These include: the lua interpreter, the database, the key store and the options. @@ -120,9 +120,9 @@ Status: landed on mainline # n.v.m.partialpull and n.v.m.gaps -Contact: ChristofPetig and MarkusSchiltknecht respectively +Contact: [[ChristofPetig]] and [[MarkusSchiltknecht]] respectively -Both branches are about partial pulls, i.e. storing only revisions newer than those of a certain horizon (including them). See PartialPull for more information and a nice illustration. Both branches introduce some form of a sentinel, which covers an inexistant or incomplete revision. The difference for n.v.m.gaps is, that these sentinels don't just cover all revisions from the covered one until the root (null revision), but to any arbitrary revision, from which we have the revision data again. +Both branches are about partial pulls, i.e. storing only revisions newer than those of a certain horizon (including them). See [[PartialPull]] for more information and a nice illustration. Both branches introduce some form of a sentinel, which covers an inexistant or incomplete revision. The difference for n.v.m.gaps is, that these sentinels don't just cover all revisions from the covered one until the root (null revision), but to any arbitrary revision, from which we have the revision data again. For more information, see this mailing list thread here: http://lists.gnu.org/archive/html/monotone-devel/2007-05/msg00185.html @@ -130,7 +130,7 @@ Status: Experimentation # n.v.m.botan -Contact: MarkusSchiltknecht or TimothyBrownawell +Contact: [[MarkusSchiltknecht]] or [[TimothyBrownawell]] This is the staging branch for Botan, i.e. where we manually propagate new upstream Botan versions to, before landing on mainline. See also botan/README.botan-monotone. @@ -138,7 +138,7 @@ Status: Botan version 1.7.4 landed on ma # n.v.m.botan.system-switch -Contact: MarkusSchiltknecht +Contact: [[MarkusSchiltknecht]] Adds a --with-system-botan configure switch, to allow using the system provided copy of botan. Especially note, that the system provided library most probably features the assembler optimizations for SHA1, where as the bundled botan currently does not. @@ -146,7 +146,7 @@ Status: Experimentation # n.v.m.svn_import -Contact: MarkusSchiltknecht +Contact: [[MarkusSchiltknecht]] An initial attempt at importing subversion repositories into monotone. Didn't touch that for a while, as the CVS importer is still bugging me. @@ -154,15 +154,15 @@ Status: Experimentation # n.v.m.heights -Contact: ThomasMoschny +Contact: [[ThomasMoschny]] -Implemented RevisionNumbering. The branch also serves as testbed for developing and testing applications of the heights, e.g. fast restricted log and fast annotate. +Implemented [[RevisionNumbering]]. The branch also serves as testbed for developing and testing applications of the heights, e.g. fast restricted log and fast annotate. Status: Currently merged into mainline. # n.v.m.revision_diff -Contact: ThomasKeller +Contact: [[ThomasKeller]] Replaces "automate content_diff" by a generic "automate diff" command which outputs the complete changeset (including node adds, drops, renames and attribute changes) in an generic basic_io format. The actual diff is included in a "data" stanza in unified diff format. @@ -170,7 +170,7 @@ Status: Stalled for quite a long time, b # n.v.m.commit_without_-b -Contact: ThomasKeller +Contact: [[ThomasKeller]] An attempt to remove the --branch option from "mtn commit" and replace the functionality by a new "mtn branch" command which explicitely sets the branch stanza in _MTN/options. This basically works, but is not thoroughly thought through for now, basically because we loose the old branch information after "mtn branch", so subsequent commands like "mtn update" which still rely on the old_revision and the recorded branch name fail badly unless the workspace is committed again. So, what still needs to be done is @@ -183,7 +183,7 @@ Status: Stalled, decide what to do with # n.v.m.experiment.informal_messages_to_stdio -Contact: ThomasKeller +Contact: [[ThomasKeller]] An attempt to bring warnings and informal messages properly encoded into automate stdio. @@ -191,7 +191,7 @@ Status: Doesn't compile, not even alpha # n.v.m.automate-netsync and n.v.m.automate-stdio-ticker -Contact: ThomasKeller +Contact: [[ThomasKeller]] The former brings push/pull/sync to automate, while the latter tries to implement a stdio ticker so automate clients can actually monitor the progress of a netsync operation. @@ -199,7 +199,7 @@ Status: Unusable, should probably be sus # n.v.m.lapo.color -Contact: LapoLuchini +Contact: [[LapoLuchini]] Making use of extra terminal features that may be available, such as colours (useful for diff and for asciik branch-lines). @@ -207,7 +207,7 @@ Status: rough and experimental # n.v.m.automate_show_conflict -Contact: StephenLeake +Contact: [[StephenLeake]] Goal: Provide simple flow to resolve non-content conflicts. @@ -217,9 +217,9 @@ Status: Just started; 'automate show_con # n.v.m.experimental.win32_pipes -Contact: StephenLeake +Contact: [[StephenLeake]] -mtn sync file: and mtn sync ssh: do _not_ work reliably on Windows MinGW. +mtn sync file: and mtn sync ssh: do _not_ work reliably on Windows [[MinGW]]. There core problem is that Win32 does not support 'select' on pipes. @@ -233,9 +233,9 @@ Status: on hold; use Cygwin instead, whe # n.v.m.experimental.win32_pipes_2 -Contact: StephenLeake +Contact: [[StephenLeake]] -Second attempt to fix mtn sync file: and mtn sync ssh: on Windows MinGW. +Second attempt to fix mtn sync file: and mtn sync ssh: on Windows [[MinGW]]. See n.v.m.experimental.win32_pipes @@ -247,7 +247,7 @@ Status: on hold; no actual work beyond p # n.v.m.TEMPLATE -Contact: WikiName +Contact: [[WikiName]] *Synopsis* ============================================================ --- wiki/BuildingOnMac.mdwn 71088dbe84d0c3322a515f5f15ffcc191e7bb73e +++ wiki/BuildingOnMac.mdwn 8a31e9115514dbbe8f824c04df3a57a5fc0de28b @@ -29,8 +29,8 @@ Once you have a working monotone, then t % monotone --db=mt.db read < should make sure that this ends up adding Potato.c, not potato.c. (This might solve previous automatically.) * More generally, users of these filesystems expect not to have to be careful about case when specifying commands. So, for instance, "monotone revert potato.c" -> "error: no such file" -- "but it's right there! stupid program". This applies to all commands that take filename arguments -- all restrictions, etc. * Proposed solution: ? ============================================================ --- wiki/CertCleanup.mdwn 35d1c167e8b838597c2664e20f4fe8f5e986b231 +++ wiki/CertCleanup.mdwn b98d0f049ab845bf865ddfa6f54e9b9635c6eb3f @@ -1,14 +1,14 @@ [[!tag migration-auto]] -While we're doing VersionedPolicy, we probably want to take the opportunity to clean up some stuff about how we do certs. +While we're doing [[VersionedPolicy]], we probably want to take the opportunity to clean up some stuff about how we do certs. Some thoughts: * should we namespace certs, like we do attrs? I.e., have cert names like `mtn:branch`, `mtn:author`, etc.? - * BranchRenaming is hard, because literal branch names are tied too closely to branch certs, and changing literal cert values is hard (as noted in UsingCerts). The fix is not to allow certs to be changed, but to abstract branch names from cert values using VersionedPolicy. + * [[BranchRenaming]] is hard, because literal branch names are tied too closely to branch certs, and changing literal cert values is hard (as noted in [[UsingCerts]]). The fix is not to allow certs to be changed, but to abstract branch names from cert values using [[VersionedPolicy]]. * certs should have ids, like other objects -- so that we can refer to them when necessary. (This is useful for packet commands, for stating which certs should be trusted, etc.) * perhaps make the cert format basic_io and documented? add a format version number too, while at it (though it's hard to imagine what would change about certs, them just being tuples and all). * review how we're doing things like formatting cryptographic data to make sure that it's all up to snuff. * possibly, add "issued by" and "date" fields. - * certs currently state the key they are signed by by referring to its key id. key ids are currently generated by hashing the actual key, plus the key's associated name. In a VersionedPolicy world, key names are no longer intrinsic properties of keys, but can be different over time (and space -- one key may exist in multiple namespaces); so perhaps these key hashes should change. + * certs currently state the key they are signed by by referring to its key id. key ids are currently generated by hashing the actual key, plus the key's associated name. In a [[VersionedPolicy]] world, key names are no longer intrinsic properties of keys, but can be different over time (and space -- one key may exist in multiple namespaces); so perhaps these key hashes should change. * combining date/author/changelog certs into a single cert would save a bunch of space and tie the date that someone said something together. (currently there is ambiguity on revs that have multiple date/author/changelog certs in terms of who said what, when). including branch certs into this new big cert might also be a good thing. * change our invariants so that we simply don't store certs that we can't verify. treat keys as preconditions to accepting certs, just like we already treat revisions as preconditions to accepting certs. don't bother writing out certs that have invalid signatures -- they are essentially malformed data, like a revision without a manifest stanza or the like. this means we don't have to verify signatures at runtime -- expensive! -- but avoids adding all sorts of annoying cache consistency logic. ============================================================ --- wiki/CvsImport.mdwn 4fc4948dfc4c34041b31705275aa84f8320a14e9 +++ wiki/CvsImport.mdwn ef2d8c06ec67e31752a19c9a377a705394ee2c4d @@ -1,8 +1,8 @@ [[!tag migration-auto]] # Importing CVS repositories with Graph Based Algorithms -The cvs2svn people, mainly Michael Haggerty have come up with a new algorithm (see his [mail](http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1451)) for cvs2svn 2.0, which is based on [GraphTheory](http://en.wikipedia.org/wiki/Graph_theory). In the branch net.venge.monotone.cvsimport-branch-reconstruction, MarkusSchiltknecht maintains an implementation in C++, with some monotone specific modifications. +The cvs2svn people, mainly Michael Haggerty have come up with a new algorithm (see his [mail](http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1451)) for cvs2svn 2.0, which is based on [GraphTheory](http://en.wikipedia.org/wiki/Graph_theory). In the branch net.venge.monotone.cvsimport-branch-reconstruction, [[MarkusSchiltknecht]] maintains an implementation in C++, with some monotone specific modifications. ## Overview ============================================================ --- wiki/CvsSync.mdwn 617f0bc498807610e0f7543bd6b8af0218728690 +++ wiki/CvsSync.mdwn 4bda33be56d36b2dba1dd9ba3107100fa693f692 @@ -1,3 +1,3 @@ [[!tag migration-auto]] +see [[CvsSyncHints]] and [[CvsSyn3]] -see CvsSyncHints and CvsSyn3 ============================================================ --- wiki/CvsSync3.mdwn 95c054e3e073c9d6347ad1006e433950bbe6e051 +++ wiki/CvsSync3.mdwn 693d7a2c5c75a849a3195880ee732cfb1739975c @@ -1,16 +1,16 @@ [[!tag migration-auto]] -# CvsSync rewrite #3 +# [[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. + - [[CvsSync3]] uses attributes to store information about file revisions and metadata and directory metadata. Repository metadata is stored as root directory attributes. - - CvsSync interfaces cvs and mtn via pipes + - [[CvsSync]] interfaces cvs and mtn via pipes - - CvsSync (mtn_cvs) uses mtn infrastructure (ui.hh, sanity.hh, options.hh) while beeing an executable on its on + - [[CvsSync]] (mtn_cvs) uses mtn infrastructure (ui.hh, sanity.hh, options.hh) while beeing an executable on its on - - CvsSync includes a C++ class interface to monotone automate process ! + - [[CvsSync]] includes a C++ class interface to monotone automate process ! Notes on discussion with Nathaniel during Monday ============================================================ --- wiki/DatabaseLocking.mdwn 8db279febdc86dca598a5a0346708c93052f9767 +++ wiki/DatabaseLocking.mdwn 840b19f235d0cba2303bab02ac336070ece0bf3b @@ -15,7 +15,7 @@ Sqlite does save us from "dirty" reads; # 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". + * [[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 ============================================================ --- wiki/DeltaStorageStrategies.mdwn c26eaa90d7afa2472b6857116907ca3c3b18186e +++ wiki/DeltaStorageStrategies.mdwn 9aeef3ce1d8016fba4407bd286f6cc7d6ffb191a @@ -8,7 +8,7 @@ Here are some of the known ways one *cou * forwards linear-chained deltas with occasional full-text breaks * forwards deterministic skip-deltas (like svn) * forwards/backwards randomized skip-deltas (like classical skip-lists) - * single base plus many deltas against it -- i.e., store a->b->c->d as (a, a->b, a->c, a->d), creating a new base as deltas grow. these pretty much have to be forwards deltas. (D. Richard Hipp, "XDFS-f" in [Josh MacDonald's masters thesis](http://xmailserver.org/xdfs.pdf) (who cites Burns and Long)) + * single base plus many deltas against it -- i.e., store a->b->c->d as (a, a->b, a->c, a->d), creating a new base as deltas grow. these pretty much have to be forwards deltas. (D. Richard Hipp, "XDFS-f" in [Josh [[MacDonald]]'s masters thesis](http://xmailserver.org/xdfs.pdf) (who cites Burns and Long)) * 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?). @@ -76,4 +76,4 @@ Store a whole revlog-style whole-base+de # Shootout +How do we choose? [[DeltaStorageStrategies]]/ShootOut -How do we choose? DeltaStorageStrategies/ShootOut ============================================================ --- wiki/Feature/AccessControl.mdwn 9a980522aa353e2bf88be5142809bf9cf58c464c +++ wiki/Feature/AccessControl.mdwn fd35de82b389278ed8efaf000258678216bcb5c4 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -10,24 +10,24 @@ Monotone has extensive and extremely pow 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 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. -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. +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. +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 Manual and Tutorial Sections: - * TrustFoundations and UsingCerts + * [[TrustFoundations]] and [[UsingCerts]] * [Trust Evaluation Hooks](http://venge.net/monotone/monotone.html#Hooks) * [Netsync Permission Hooks](http://venge.net/monotone/monotone.html#Hooks) Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureACL](http://wikitest.freebsd.org/VCSFeatureACL) - * FreeBSD [VCSFeatureACL](http://wikitest.freebsd.org/VCSFeatureACL) ============================================================ --- wiki/Feature/AtomicCommit.mdwn 29c3d2e76767abc306f1d60675c43d6da45d010c +++ wiki/Feature/AtomicCommit.mdwn 62cbb1633b28a91f02d70fc6d57d88d4f88053f1 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -12,7 +12,7 @@ In addition, you can `commit` at any tim 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. +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 @@ -23,8 +23,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: * [Dealing with a Fork](http://venge.net/monotone/monotone.html#Dealing-with-a-Fork) - * CommitEarlyCommitOften + * [[CommitEarlyCommitOften]] Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureAtomicCommit](http://wikitest.freebsd.org/VCSFeatureAtomicCommit) - * FreeBSD [VCSFeatureAtomicCommit](http://wikitest.freebsd.org/VCSFeatureAtomicCommit) ============================================================ --- wiki/Feature/BuildIntegration.mdwn 7cf28bf652e834abd5ad675cee39c066bce70fc8 +++ wiki/Feature/BuildIntegration.mdwn 34c48ffeae8871727704d52876d5f142ac3297f1 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,9 +8,9 @@ It should be possible to trigger build a # 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 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. +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 @@ -21,4 +21,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureTinderbox](http://wikitest.freebsd.org/VCSFeatureTinderbox) - * FreeBSD [VCSFeatureTinderbox](http://wikitest.freebsd.org/VCSFeatureTinderbox) ============================================================ --- wiki/Feature/CVSExport.mdwn 556a28b5c3d69f1d78d5c85efd1c9524b37b0869 +++ wiki/Feature/CVSExport.mdwn 0ee0c4d5bd1c11d140fdd94ac78f2bc8af763d83 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,9 +8,9 @@ Put revisions committed to monotone back # Not (yet) Supported -This is not yet supported in mainline monotone, but there is experimental code on a branch which does this (see BranchStatuses). +This is not yet supported in mainline monotone, but there is experimental code on a branch which does this (see [[BranchStatuses]]). -Allowing developers to use ["MonotoneAndCVS"] together in several different ways is an explicit goal of this effort, but it is complicated by the well-known limitations of CVS. In particular, accurately representing the DAG-structure of monotone commits in a linear CVS history presents special challenges. +Allowing developers to use ["[[MonotoneAndCVS]]"] together in several different ways is an explicit goal of this effort, but it is complicated by the well-known limitations of CVS. In particular, accurately representing the DAG-structure of monotone commits in a linear CVS history presents special challenges. 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. @@ -18,4 +18,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureCVSExport](http://wikitest.freebsd.org/VCSFeatureCVSExport) - * FreeBSD [VCSFeatureCVSExport](http://wikitest.freebsd.org/VCSFeatureCVSExport) ============================================================ --- wiki/Feature/CVSImport.mdwn 6ab438123ca3a3e8ce797e9980cad6a67a2e48e5 +++ wiki/Feature/CVSImport.mdwn 1ebd307f9eafad6cd3d1bf1f81bb32f033a60e24 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,7 +8,7 @@ The ability to import past project histo # 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"]. +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. @@ -28,4 +28,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureCVSImport](http://wikitest.freebsd.org/VCSFeatureCVSImport) - * FreeBSD [VCSFeatureCVSImport](http://wikitest.freebsd.org/VCSFeatureCVSImport) ============================================================ --- wiki/Feature/CommitMail.mdwn 89a11b26992613af019bb03339f84e39d149cc3d +++ wiki/Feature/CommitMail.mdwn 41391462d99ab161d25619812ec51a0dc5651ce6 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -10,7 +10,7 @@ Monotone supports this and many similar 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 [CIA](http://cia.navi.cx/stats/project/monotone), from where the notifications can also be sent to IRC channels and RSS feeds. +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 [CIA](http://cia.navi.cx/stats/project/monotone), from where the notifications can also be sent to IRC channels and RSS feeds. # Further Reference @@ -20,4 +20,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureCommitMail](http://wikitest.freebsd.org/VCSFeatureCommitMail) - * FreeBSD [VCSFeatureCommitMail](http://wikitest.freebsd.org/VCSFeatureCommitMail) ============================================================ --- wiki/Feature/CompactRepository.mdwn b48a906da90d11320ff31160b530d347cccf999c +++ wiki/Feature/CompactRepository.mdwn ae47674eb6960d3b72dbdff490e580ea202630c1 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -16,7 +16,7 @@ The database format is machine- and endi 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. -See also: FeatureRobustRepository +See also: [[FeatureRobustRepository]] ## = Example Usage = ## @@ -40,4 +40,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureGoodRepositoryFormat](http://wikitest.freebsd.org/VCSFeatureGoodRepositoryFormat) - * FreeBSD [VCSFeatureGoodRepositoryFormat](http://wikitest.freebsd.org/VCSFeatureGoodRepositoryFormat) ============================================================ --- wiki/Feature/EmbeddedIDs.mdwn 38cfd1a7656f31457ed769d76b0b442a15baa8fb +++ wiki/Feature/EmbeddedIDs.mdwn ef1123bdbf5da65e9d178ada663d70c0b84b0519 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -18,4 +18,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureDollarFreeBSD](http://wikitest.freebsd.org/VCSFeatureDollarFreeBSD) - * FreeBSD [VCSFeatureDollarFreeBSD](http://wikitest.freebsd.org/VCSFeatureDollarFreeBSD) ============================================================ --- wiki/Feature/Fast.mdwn 250564ec5967e68a77cc0594d918f5a03fa7bf08 +++ wiki/Feature/Fast.mdwn f5ca9c5143b32c6816091d0be9bf1ebf75cce80c @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -10,7 +10,7 @@ Monotone is fast for many operations, in 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. -Monotone has been implemented for robustness and correctness first, and optimisation later. It includes extensive internal consistency checking and revalidation of information (see FeatureRobustRepository) and this comes at some cost in performance. The implementations of some key internal operations have been initially written for clarity and simplicity rather than efficiency, and some are known to be downright wasteful of CPU. These are being optimised or rewritten as benchmarking shows where the hotspots are; this can be done with confidence on the basis of the extensive test suite that ensures correct behaviour is retained with new implementations. +Monotone has been implemented for robustness and correctness first, and optimisation later. It includes extensive internal consistency checking and revalidation of information (see [[FeatureRobustRepository]]) and this comes at some cost in performance. The implementations of some key internal operations have been initially written for clarity and simplicity rather than efficiency, and some are known to be downright wasteful of CPU. These are being optimised or rewritten as benchmarking shows where the hotspots are; this can be done with confidence on the basis of the extensive test suite that ensures correct behaviour is retained with new implementations. Some operations are known to scale poorly on repositories with very deep histories, even though the problem may not be noticable on newer projects with shorter histories. The 0.30 release introduced major performance improvements as a result of applying this process to some key areas, and further work is ongoing to continue this process for more elements and internal operations. @@ -30,4 +30,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureFast](http://wikitest.freebsd.org/VCSFeatureFast) - * FreeBSD [VCSFeatureFast](http://wikitest.freebsd.org/VCSFeatureFast) ============================================================ --- wiki/Feature/LightweightBranches.mdwn 8e9b5849c95877a39d242f75bbb4daa9052ffb38 +++ wiki/Feature/LightweightBranches.mdwn 113eaacc5fdd34c6330a8b4aa2dec2280ccc1d99 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -10,9 +10,9 @@ Monotone's implementation of branches is 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). +Monotone also has very robust and powerful merging capabilities (see [[FeatureMerging]]). # Example Usage @@ -29,4 +29,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureBranch](http://wikitest.freebsd.org/VCSFeatureBranch) - * FreeBSD [VCSFeatureBranch](http://wikitest.freebsd.org/VCSFeatureBranch) ============================================================ --- wiki/Feature/LogReview.mdwn 7b828c6c426ed291483945466cc788939b6ed374 +++ wiki/Feature/LogReview.mdwn 912ff658418d96d163c6a900731a368318b014d9 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -14,7 +14,7 @@ Note that these hooks are run on individ # Example Usage -See also: UsingCerts +See also: [[UsingCerts]] # Further Reference @@ -24,4 +24,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureLogReview](http://wikitest.freebsd.org/VCSFeatureLogReview). Note that the example given talks about "approved by: re" messages. While these might be appropriate in logs too, monotone has much more extensive and flexible mechanisms to handle approval of revisions for particular purposes and branches. See [[TrustFoundations]] and [[FeatureAccessControl]]. - * FreeBSD [VCSFeatureLogReview](http://wikitest.freebsd.org/VCSFeatureLogReview). Note that the example given talks about "approved by: re" messages. While these might be appropriate in logs too, monotone has much more extensive and flexible mechanisms to handle approval of revisions for particular purposes and branches. See TrustFoundations and FeatureAccessControl. ============================================================ --- wiki/Feature/LogTemplates.mdwn 9294afc331b443216e9b06044754fa166d9bca56 +++ wiki/Feature/LogTemplates.mdwn ac6cf94eb237a6feba601581e4a5240122907f6c @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,12 +8,12 @@ Commit log messages should start from a # 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. +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. +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 Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureLogTemplates](http://wikitest.freebsd.org/VCSFeatureLogTemplates) - * FreeBSD [VCSFeatureLogTemplates](http://wikitest.freebsd.org/VCSFeatureLogTemplates) ============================================================ --- wiki/Feature/MIMEtypes.mdwn 1c93be76be7daa2781de294197237b2df440da32 +++ wiki/Feature/MIMEtypes.mdwn 2689db6ba3008991214115f9644d5873d476a864 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -24,4 +24,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureMIMEType](http://wikitest.freebsd.org/VCSFeatureMIMEType) - * FreeBSD [VCSFeatureMIMEType](http://wikitest.freebsd.org/VCSFeatureMIMEType) ============================================================ --- wiki/Feature/Merging.mdwn 3e6ad644cd409923ff27f7feca34170660ba6b98 +++ wiki/Feature/Merging.mdwn 64d10b953c8de7c089998d8adda7794d7790fa0a @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -34,8 +34,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: * [Branching and Merging](http://venge.net/monotone/monotone.html#Branching-and-Merging) - * DaggyFixes and ZipperMerge + * [[DaggyFixes]] and [[ZipperMerge]] Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureMerging](http://wikitest.freebsd.org/VCSFeatureMerging) - * FreeBSD [VCSFeatureMerging](http://wikitest.freebsd.org/VCSFeatureMerging) ============================================================ --- wiki/Feature/Mirroring.mdwn ccf230c59e54ac08d5bea1085c505eef2ad04cb5 +++ wiki/Feature/Mirroring.mdwn 1f8f6f3389430038e71ea158bfd90288e6311520 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -23,7 +23,7 @@ If either of these servers had new revis If either of these servers had new revisions, those revisions will be transferred to the developer's database, and then to the other server if it was not yet aware of them. In order to make them identical mirrors, use the branch pattern `'*'` for all syncs, otherwise more selective patterns can be used for partial replicas. -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. +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 @@ -33,4 +33,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureMirroring](http://wikitest.freebsd.org/VCSFeatureMirroring) - * FreeBSD [VCSFeatureMirroring](http://wikitest.freebsd.org/VCSFeatureMirroring) ============================================================ --- wiki/Feature/NetworkSecurity.mdwn 248ae3673807f8fad3eeb1a770aef7a8063bc903 +++ wiki/Feature/NetworkSecurity.mdwn 594d7d68bf4ce54ccf7172a794ea5a052b833458 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -26,4 +26,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureNetworkSecure](http://wikitest.freebsd.org/VCSFeatureNetworkSecure) - * FreeBSD [VCSFeatureNetworkSecure](http://wikitest.freebsd.org/VCSFeatureNetworkSecure) ============================================================ --- wiki/Feature/Obliterate.mdwn 09055fc196d97ff69255eee7b48bc4f79d1b96d4 +++ wiki/Feature/Obliterate.mdwn 132fb91bd79ee9985b57d55ab381d4f74e58cfac @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -34,4 +34,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureObliterate](http://wikitest.freebsd.org/VCSFeatureObliterate) - * FreeBSD [VCSFeatureObliterate](http://wikitest.freebsd.org/VCSFeatureObliterate) ============================================================ --- wiki/Feature/Offline.mdwn 5b5d54da51bd028c17536df9be9a67b5d9c419df +++ wiki/Feature/Offline.mdwn a6d9631c23fcc0c19b2cb202957e145c90544ddc @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -33,4 +33,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureOffline](http://wikitest.freebsd.org/VCSFeatureOffline) - * FreeBSD [VCSFeatureOffline](http://wikitest.freebsd.org/VCSFeatureOffline) ============================================================ --- wiki/Feature/Portable.mdwn 06e63ae72cf35251468a0fb0e8fe6ba7915d044a +++ wiki/Feature/Portable.mdwn e1d50d7cafdc0e0f89f0c78bce3629202afe47a9 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,11 +8,11 @@ The VCS tools should be portable to run # 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. +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 Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeaturePortable](http://wikitest.freebsd.org/VCSFeaturePortable) - * FreeBSD [VCSFeaturePortable](http://wikitest.freebsd.org/VCSFeaturePortable) ============================================================ --- wiki/Feature/Rename.mdwn ed367b3a722dce6e2e7310318399292bdb3d1f0b +++ wiki/Feature/Rename.mdwn 1dfa84a25d2b4e378a8feab86291bcaaf0b9d37b @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -24,8 +24,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Manual Section Name](http://venge.net/monotone/monotone.html#SectionName) + * [Manual Section Name](http://venge.net/monotone/monotone.html#[[SectionName]]) Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureRename](http://wikitest.freebsd.org/VCSFeatureRename) - * FreeBSD [VCSFeatureRename](http://wikitest.freebsd.org/VCSFeatureRename) ============================================================ --- wiki/Feature/RobustRepository.mdwn 2d8363d5a47b997ab8427b41d5821886867b2856 +++ wiki/Feature/RobustRepository.mdwn 023e466445479a3ad974398c8605a12ff49e64a7 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -16,7 +16,7 @@ Although the database storage layer is S Although the database storage layer is SQL, this is embedded within monotone; knowledge of SQL or the schema is invisible and irrelevant for all regular use. Even so, it is nice to know that SQL tools can be used when needed for extremely specialised operations. These circumstances usually amount to either debugging monotone, or specialised one-off administrative tasks that usually indicate the need for additional UI commands to be developed. The database storage layer and schema is also well isolated and abstracted within the monotone codebase: all the core algorithms and UI operations are entirely storage-agnostic, allowing other storage implementations or schema changes as needed. -See also: FeatureCompactRepository +See also: [[FeatureCompactRepository]] # Example Usage @@ -30,4 +30,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureGoodRepositoryFormat](http://wikitest.freebsd.org/VCSFeatureGoodRepositoryFormat) - * FreeBSD [VCSFeatureGoodRepositoryFormat](http://wikitest.freebsd.org/VCSFeatureGoodRepositoryFormat) ============================================================ --- wiki/Feature/SignedRevisions.mdwn 6b25cd81b0a1430c6346e0aa09a5dcee09d517cc +++ wiki/Feature/SignedRevisions.mdwn 5e0760f7279533c01d8820e7eabc3ad215c7ca65 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -23,8 +23,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: * [Certificates](http://venge.net/monotone/monotone.html#Certificates) - * TrustFoundations and UsingCerts + * [[TrustFoundations]] and [[UsingCerts]] Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureSign](http://wikitest.freebsd.org/VCSFeatureSign) - * FreeBSD [VCSFeatureSign](http://wikitest.freebsd.org/VCSFeatureSign) ============================================================ --- wiki/Feature/Symlinks.mdwn 9a6ba18289105562cb358341f9b5c2300196998f +++ wiki/Feature/Symlinks.mdwn 180df0600f90c1e0e095636fc8a08a6f42137e15 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -12,10 +12,10 @@ Monotone ignores symlinks by default, bu # Example Usage -See UnixAttribsAndSymlinks +See [[UnixAttribsAndSymlinks]] # Further Reference Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureSymlinks](http://wikitest.freebsd.org/VCSFeatureSymlinks) - * FreeBSD [VCSFeatureSymlinks](http://wikitest.freebsd.org/VCSFeatureSymlinks) ============================================================ --- wiki/Feature/VendorBranches.mdwn 38defee445822db452e3987c83bf9733a7b46e57 +++ wiki/Feature/VendorBranches.mdwn 633542b06c347681cd56e9596837b82c85400887 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -17,10 +17,10 @@ There are two aspects to this requiremen # 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 Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureVendorBranches](http://wikitest.freebsd.org/VCSFeatureVendorBranches) - * FreeBSD [VCSFeatureVendorBranches](http://wikitest.freebsd.org/VCSFeatureVendorBranches) ============================================================ --- wiki/Feature/WebInterface.mdwn 2bae6d76f591164fbc353bcf98bd67e1c6767ed5 +++ wiki/Feature/WebInterface.mdwn 9294b668202df884f61bd3b643b20c9fad27bfdf @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. +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 @@ -8,11 +8,11 @@ A web-based interface should allow for e # Supported -There are a number of InterfacesFrontendsAndTools that work with monotone, including several web-based ones. Monotone's own sources can be browsed using [ViewMTN](http://grahame.angrygoats.net/viewmtn.shtml), and there is also a [Trac plugin](http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/) under development. +There are a number of [[InterfacesFrontendsAndTools]] that work with monotone, including several web-based ones. Monotone's own sources can be browsed using [ViewMTN](http://grahame.angrygoats.net/viewmtn.shtml), and there is also a [Trac plugin](http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/) under development. # Example Usage - * [Recent monotone activity, via ViewMTN](http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone) + * [Recent monotone activity, via [[ViewMTN]]](http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone) * [Current monotone HEAD revision](http://viewmtn.angrygoats.net/headofbranch.psp?branch=net.venge.monotone) * [Trac-monotone demonstration](http://trac.h975245.serverkompetenz.net/) * [Recent monotone activity, via CIA](http://cia.navi.cx/stats/project/monotone) @@ -22,4 +22,4 @@ Features and Requirements in other evalu Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureWebInterface](http://wikitest.freebsd.org/VCSFeatureWebInterface) - * FreeBSD [VCSFeatureWebInterface](http://wikitest.freebsd.org/VCSFeatureWebInterface) ============================================================ --- wiki/FileSystemIssues.mdwn db6944e7812bc8ad2f409c47a9d10c7adc348244 +++ wiki/FileSystemIssues.mdwn 79508659be4b804c851f76b05b50e08fba178c5a @@ -1,9 +1,9 @@ About: Encoding, platform independency a [[!tag migration-auto]] # File System Issues in Monotone About: Encoding, platform independency and case of filenames (codepages and unicode)
-Related: CaseInsensitiveFilesystems +Related: [[CaseInsensitiveFilesystems]] Last updated with monotone version 0.32 @@ -24,7 +24,7 @@ directoryname and filename can be used s a. You add the file using recursion, which will lead monotone to add a decomposed (NFD) UTF-8 filename. a. You can add the file using the full path, which will lead monotone to add precomposed (NFC) UTF-8 filename. a. To drop this file you need to drop it once using your keyboards umlauts (precomposed). (i.e löl) and once using bash's completion: lo-tab -> löl (decomposed). See "About UTF-8 normalization" below. - 4. Case insensitive file systems lead to the same problem as in 3 and sometimes to even more problems: CaseInsensitiveFilesystems + 4. Case insensitive file systems lead to the same problem as in 3 and sometimes to even more problems: [[CaseInsensitiveFilesystems]] Now for the speculation... @@ -56,9 +56,9 @@ Microsoft recommends to use the wide ver Microsoft recommends to use the wide version of all file system layer accessing function. - 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. + 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] @@ -138,7 +138,7 @@ Write == A filename is written to local 1. Do conversions on read (from locale to UTF-8) and write (from UTF-8 to locale) of filenames on POSIX, except Darwin. 2. Do conversions on read (from UTF-8 (NFD) to UTF-8 (NFC)) and none on write of filenames on Darwin. 3. One of the following solutions on windows: - 1. Do conversions on read (from locale to UTF-8) and write (from UTF-8 to locale) and use new libidn or GetACP() to find out what the local locale is. + 1. Do conversions on read (from locale to UTF-8) and write (from UTF-8 to locale) and use new libidn or [[GetACP]]() to find out what the local locale is. 2. Use the wide versions of file system accessing functions on windows, which should return UTF-16. So you need to do conversions on read (from UTF-16 to UTF-8) and write (from UTF-8 to UTF-16). 3. Use setlocale() to set UTF-8 and do no conversion. This differs from POSIX because win32's file system layer will do conversions. Tests on NTFS and FAT need to be done before using this solution. 4. Convert all filenames to lower case for internal use, but save the filenames with case-information in the database, comparing should happen on uniform case. Write a nice error message on an add command, stating that the error could be caused by monotone not supporting case-sensitive filenames for the reason that there are case-insensitve file systems. Offer to rename that file. @@ -152,7 +152,7 @@ Write == A filename is written to local 12. I added this "offer rename" statements because there are errors you can get on a checkout/update. So if you have no workspace (no update), you can't rename, if you can't rename you can get no workspace (no update). Therefore we need to offer some means of renaming while checking out or updating. 13. There must be a migration function if we really are going to do 4., files which only differ in case must be listed and means of renaming them must be provided, when updating to the monotone version which implements 4.. -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. +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. @@ -182,7 +182,7 @@ Wrong guess! ### 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(). +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 ============================================================ --- wiki/FutureCryptography.mdwn 6688192080db144f2b46722e211aee21d6805c87 +++ wiki/FutureCryptography.mdwn a42aa284e8285cc08978acbf3a6b0292519a1642 @@ -16,7 +16,7 @@ Should Monotone migrate to supporting mo * But a lot about Monotone works because there's a single hash function. I'd like to hear from those who know on what issues might be raised if a history uses more than one hash function. * We have to consider carefully the security implications of supporting more than one - can an attacker just use the least secure one? -There are some interactions with VersionedPolicy here. Perhaps hash functions would need to be mandated by policy. +There are some interactions with [[VersionedPolicy]] here. Perhaps hash functions would need to be mandated by policy. 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. @@ -25,11 +25,11 @@ As well as the hash function change, two As well as the hash function change, two other changes will impact on public key signatures: * Graydon proposes to change the Monotone cert format to make a single cert do the work of several, which makes sense. - * VersionedPolicy + * [[VersionedPolicy]] -We should of course try to bring in all of these changes (and any resulting from the discussion below) at the same time to bring us down to one Flag Day. VersionedPolicy may also play a role in making some of this more straightforward. +We should of course try to bring in all of these changes (and any resulting from the discussion below) at the same time to bring us down to one Flag Day. [[VersionedPolicy]] may also play a role in making some of this more straightforward. -We should use "principals" - ie key fingerprints - everywhere we use keys. For that matter we should use them where we use email addresses too for the most part, though some of that comes under the heading of VersionedPolicy. +We should use "principals" - ie key fingerprints - everywhere we use keys. For that matter we should use them where we use email addresses too for the most part, though some of that comes under the heading of [[VersionedPolicy]]. We can reduce the computational burden of signature checking down to practically nothing with a couple of simple tricks: ============================================================ --- wiki/Glossary.mdwn bbc004729dc2696bc995943758a90fca5b4137b4 +++ wiki/Glossary.mdwn 863cede393851dce1412cd5d13a3e8be54cc0f85 @@ -12,13 +12,13 @@ Domain:: Monotone uses this term to describe a group of variables held on a database. [[Anchor(Edge)]] - Edge:: The changes that come from one [#Revision revision] to a descendant. A merge would have more than one edge. In a [#DirectedAcyclicGraph Directed Acyclic Graph], one of the arrows, as opposed to one of the points. + Edge:: The changes that come from one [#Revision revision] to a descendant. A merge would have more than one edge. In a [#[[DirectedAcyclicGraph]] Directed Acyclic Graph], one of the arrows, as opposed to one of the points. [[Anchor(Endpoints)]] Endpoints:: `Need a definition here` "By restricting the set of trusted testresult certificates, you can require that the endpoints of an update operation have a certificate asserting that the revision in question passed a certain test, or testsuite." [[Anchor(DirectedGraph)]] - 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]. + 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*. @@ -30,7 +30,7 @@ Man In The Middle Attack:: A way of intercepting key-encrypted information sent between two parties (Alice and Bob) without either of them knowing. The third party pretends to Alice that they are Bob, and to Bob that they are Alice. This attack only works if Alice and Bob cannot authenticate each other's signatures by a second means, say, by reading each others' key hashes out over the 'phone. Monotone uses keys to prove the identity of the person signing a cert. [[Anchor(Packets)]] - Packets:: Monotone can be made to produce a text file containing a single revision. This text file is called a Packet. See also [#PacketStream Packet Stream]. + Packets:: Monotone can be made to produce a text file containing a single revision. This text file is called a Packet. See also [#[[PacketStream]] Packet Stream]. [[Anchor(PacketStream)]] Packet Stream:: Monotone writes data to disk in a Stream, in other words, at the time it changes. For efficiency the changes are `(presumably - help, anyone?)` sent to the database in Packets, in other words, grouped together. @@ -43,4 +43,4 @@ [[Anchor(RevisionGraph)]] + Revision Graph:: See [#[[DirectedAcyclicGraph]] Directed Acyclic Graph]. - Revision Graph:: See [#DirectedAcyclicGraph Directed Acyclic Graph]. ============================================================ --- wiki/HistoryBlueSky.mdwn a30f71e21b78ba477f75634e2d1183034a96e513 +++ wiki/HistoryBlueSky.mdwn 031c440a8cdf8ca77dd4235d00bb78d15413ee83 @@ -1,10 +1,10 @@ Space-age things that would be cool to s [[!tag migration-auto]] Space-age things that would be cool to support in our history representation (though not strictly necessary): # Suturing -**Use case:** Melding together trees that were separately imported. For instance, PeterSimons (used to?) use monotone to manage his [unified autoconf archive](http://autoconf-archive.cryp.to/) -- 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 [unified autoconf archive](http://autoconf-archive.cryp.to/) -- 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. ============================================================ --- wiki/I18nL10n.mdwn d37ff66e52e735ebd40be12a9fa0f46f7933ff0e +++ wiki/I18nL10n.mdwn 1632832ccfdd9a776c6af5860400bf2fb4193d09 @@ -43,7 +43,7 @@ We should probably audit everything deal ## Composition/decomposition -It is possible that there are filesystems which somehow normalize unicode strings. (E.g., [HFS+ on OS X](http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties) 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, [SVN has encountered this issue in practice](http://svn.haxx.se/users/archive-2005-12/0381.shtml). +It is possible that there are filesystems which somehow normalize unicode strings. (E.g., [HFS+ on OS X](http://developer.apple.com/technotes/tn/tn1150.html#[[UnicodeSubtleties]]) 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, [SVN has encountered this issue in practice](http://svn.haxx.se/users/archive-2005-12/0381.shtml). Other useful OS X links: * [Converting to Precomposed Unicode](http://developer.apple.com/qa/qa2001/qa1235.html) ============================================================ --- wiki/LineEndingMunging.mdwn 0e365a92a60443c2f536f45dda152542472ecd8c +++ wiki/LineEndingMunging.mdwn d74d57c344ccca47471f7f10d8e55dc12825a3e1 @@ -56,7 +56,7 @@ Unresolved issues: * eol-style=native does not actually guarantee anything; it is possible to have files in the db with inconsistent line endings and this attr on them. What should we do with such files at checkout time? Some options: * force them consistent when writing them to the workspace (i.e., normalize all line endings of whatever sort, to native). This means that 'checkout; commit' is not a no-op, because it will normalize any inconsistent line endings. * print a warning, and leave line endings alone entirely (as if there were no eol-style attr present). This means that after 'checkout', the workspace may be inconsistent -- diff will not work, etc. - * record the file in the workspace as conflicted, requiring user resolution. See NonMergeConflicts. + * record the file in the workspace as conflicted, requiring user resolution. See [[NonMergeConflicts]]. * Should we continue to support diff/merge on files that do not have a line-ending defined? The argument for "yes" is that projects that do not want to deal with this junk can just ignore it entirely, and treat all files as binary. (Like, for instance, the monotone project does now.) The argument for "no" is that it's not really that big a deal to just be eol-style-correct, given appropriate tools, and certainly easier than trying to come up with a coherent strategy for guessing all the time. * If we do require eol-style for files to be diff/merge-able, then we should probably require an explicit marking on every file either saying it is mergeable or it is not mergeable, to reduce instances where someone accidentally leaves the attr off, and then even after they fix it, the presence of a binary ancestor continues to screw up merges. ============================================================ --- wiki/MagicSelectors.mdwn fba438d23bf42372454525cc649b23a32d915428 +++ wiki/MagicSelectors.mdwn 20f0010b627dd161e6d9f41a2b6cfe9b943b6578 @@ -10,7 +10,7 @@ Apparently clearcase has something simil Apparently clearcase has something similar, and git has been developing similar notions as well -- someone should track down links to their documentation and add those here. -This page should collect ideas and template definitions for possible magic selectors. There are also some questions about how selectors should work in total, and whether selectors have any access to "context" from other parts of a compound selector. See also the Selector Syntax discussion in BranchNamingConventions. +This page should collect ideas and template definitions for possible magic selectors. There are also some questions about how selectors should work in total, and whether selectors have any access to "context" from other parts of a compound selector. See also the Selector Syntax discussion in [[BranchNamingConventions]]. # Selector Naming Styles ============================================================ --- wiki/MergeViaWorkingDir.mdwn 9ec522b844ca7550240094d97708a2ae61dab95b +++ wiki/MergeViaWorkingDir.mdwn c0ca2dbbb4ca56b2f5c644d29329f200b1bf5b41 @@ -1,10 +1,10 @@ [[!tag migration-auto]] -*Note: this page is a little out of date, and describes work in progress, not yet visible on mainline. In the mean time, consider using the ZipperMerge pattern to help with difficult merges.* +*Note: this page is a little out of date, and describes work in progress, not yet visible on mainline. In the mean time, consider using the [[ZipperMerge]] pattern to help with difficult merges.* ---- -Notes on updating commands to work with multi-parent workspaces: MultiParentWorkspaceFallout +Notes on updating commands to work with multi-parent workspaces: [[MultiParentWorkspaceFallout]] ---- Everything below needs revision. ============================================================ --- wiki/MonotoneAndCVS.mdwn d6209c3f5b6da5fe4203903121c8304f3bb4005c +++ wiki/MonotoneAndCVS.mdwn 40e719d83f48c9f867b65e72f072d426018dee81 @@ -36,7 +36,7 @@ revisions, arbitrary branch points, part reconstruction and produce a better full ancestry structure from the chaotic gas of CVS revisions, arbitrary branch points, partial and moved tags, etc etc. -This work could use some help, if anyone feels inspired.. see the BranchStatuses page :) +This work could use some help, if anyone feels inspired.. see the [[BranchStatuses]] page :) This is where the tricky issues of nasty CVS data quality and automated vs @@ -58,7 +58,7 @@ repository). back work in a private monotone branch back to the mainline CVS repository). -See also CvsSyncHints. +See also [[CvsSyncHints]]. ## cvs_takeover method ============================================================ --- wiki/MonotoneOnDebian.mdwn 316868563d1e66015b5332bc11cfc6572bc89204 +++ wiki/MonotoneOnDebian.mdwn e5923328247cbed0cfc7eb10bbc9d3269178b448 @@ -13,7 +13,7 @@ The sarge monotone packages are currentl The sarge monotone packages are currently built with [pbuilder](http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html) running on debian testing. Pbuilder basically extracts a minimal debian system (of a chosen distro) to a temporary directory, chroots there, installs neccessary build-deps, and then builds the given package. `pbuilder create` is used to create a base image (tarball). Note that `pdebuild` is easiest to run as root, due to the chrooting. -Since sarge has too old a version of boost, 1.33 is built (using pbuilder) for sarge then linked to monotone statically. [''I can't find the my build directory for boost, there probably weren't many caveats. I may have had to disable ICU support? - MattJohnston'']. The sarge boost .debs can then be placed in a directory such as `/var/cache/pbuilder/localpackages/`. Create a script `/var/cache/pbuilder/hooks/D70results` with the contents {{{ +Since sarge has too old a version of boost, 1.33 is built (using pbuilder) for sarge then linked to monotone statically. [''I can't find the my build directory for boost, there probably weren't many caveats. I may have had to disable ICU support? - [[MattJohnston]]'']. The sarge boost .debs can then be placed in a directory such as `/var/cache/pbuilder/localpackages/`. Create a script `/var/cache/pbuilder/hooks/D70results` with the contents {{{ #!/bin/sh cd /var/cache/pbuilder/localpackages/ /usr/bin/dpkg-scanpackages . /dev/null > /var/cache/pbuilder/localpackages/Packages ============================================================ --- wiki/MtnSummit/2007/LogisticsNA.mdwn 079150c07efae87e1455cdd20e217e56ff2d6080 +++ wiki/MtnSummit/2007/LogisticsNA.mdwn 8ebda54f2d0363a5de064dcd2b1b976bc13be903 @@ -12,7 +12,7 @@ The closest airport to Mountain View/San The closest airport to Mountain View/Santa Clara is San Jose International (SJC). The next closest is San Francisco International (SFO). SFO may have more international flights. Oakland also has an airport that's sort of close (OAK), but don't do that unless you have to -- it's about 2 hours of public transportation away. -If you want to use Bay Area public transportation at all, then you want to know about the ["TakeTransit Trip Planner"](http://transit.511.org/tripplanner/index.asp). +If you want to use Bay Area public transportation at all, then you want to know about the ["[[TakeTransit]] Trip Planner"](http://transit.511.org/tripplanner/index.asp). I assume if you're close enough to drive, then you can figure that out yourself. ============================================================ --- wiki/NonMergeConflicts.mdwn 4a80a8af4461f7a28082d2f60ed0e20306f5a396 +++ wiki/NonMergeConflicts.mdwn 11092391afbadd10224dface7b50b6811138afb9 @@ -18,7 +18,7 @@ An interesting thing is that many of the An interesting thing is that many of these are similar to existing merge conflicts. The problem with having two files named "A" and "a" is basically similar to the problem of merging to trees that each have a file named "a" -- there are two logical files, and they cannot both have their desired name. Forbidden filenames -- like COM1 or things unrepresentable in the current locale -- are similar to a merge that would create a file named "MT" in the root directory (this is possible when pivot_root is used). Etc. -So, the idea is just to re-use the machinery created for MergeViaWorkingDir -- when checkout or update or revert(!) would create a problem like the above, we instead create conflict stuff in the tree. This seems to neatly solve all of the above problems. In particular, we achieve the goal of letting, say, a windows user fix up a tree after someone has accidentally checked in multiple files differing only in case, without having to go find a unix box to do so. +So, the idea is just to re-use the machinery created for [[MergeViaWorkingDir]] -- when checkout or update or revert(!) would create a problem like the above, we instead create conflict stuff in the tree. This seems to neatly solve all of the above problems. In particular, we achieve the goal of letting, say, a windows user fix up a tree after someone has accidentally checked in multiple files differing only in case, without having to go find a unix box to do so. # Considerations ============================================================ --- wiki/NotesOnTestingChangesetify.mdwn b2f737820424e8b0281cfda3fd47acb828cd6a6a +++ wiki/NotesOnTestingChangesetify.mdwn 360c2233b395292730f095ad1de8403287d1329d @@ -25,7 +25,7 @@ mtn: fatal: std::logic_error: ../S-vanil ============================================================ --- cryptopp/integer.cpp f2a0e049b9aef571c5807afd972a77f377482d8f +++ cryptopp/integer.cpp e2cf6746ad5ce51d0bd2406ec07f9bcda36f5aa9 -@@ -1473,7 +1473,7 @@ void PentiumOptimized::Square4(word* Y, +@@ -1473,7 +1473,7 @@ void [[PentiumOptimized]]::Square4(word* Y, : : "D" (Y), "S" (X) @@ -46,7 +46,7 @@ mtn: fatal: std::logic_error: ../S-vanil #include // VC60 workaround: this macro is defined in shlobj.h and conflicts with a template parameter used in this file -@@ -745,8 +747,6 @@ void DL_PublicKey::AssignFrom(const N +@@ -745,8 +747,6 @@ void DL_[[PublicKey]]::[[AssignFrom]](const N } } @@ -54,7 +54,7 @@ mtn: fatal: std::logic_error: ../S-vanil - //! . template - class DL_KeyImpl : public PK + class DL_[[KeyImpl]] : public PK ============================================================ --- merkle_tree.cc 565e0f4242011220ff3b20574cff68d74552ee2a +++ merkle_tree.cc 2abde1a4a10709bec5ad40e325ce4016b1fcd0e1 ============================================================ --- wiki/People/JackLloyd.mdwn 036e54acee902b77709e28e75d8fa4cece0af467 +++ wiki/People/JackLloyd.mdwn 0536ccbe46fa7d823affe70bd886cc81b35e950e @@ -1,8 +1,8 @@ [[!tag migration-auto]] ## Jack Lloyd -Wrote/maintains Botan. Used to work on OpenCM, which was somewhat Monotone-like. +Wrote/maintains Botan. Used to work on [[OpenCM]], which was somewhat Monotone-like. Email: [[MailTo(address@hidden)]]
Webpage: http://www.randombit.net/
============================================================ --- wiki/People/JustinPatrin.mdwn 6dda38f33652fce1df493e5d5e8cbf09a1bd0ec5 +++ wiki/People/JustinPatrin.mdwn 1b5461ef8cabf9c7c2d4ce00ffa690776ced252b @@ -1,6 +1,6 @@ [[!tag migration-auto]] -A user of monotone via the [OpenEmbedded](http://openembedded.org) project. Started developing on monotone at the 2007 summit at Google with the net.venge.monotone.ssh-agent branch (see ["MonotoneAndSSHAgent"]). +A user of monotone via the [OpenEmbedded](http://openembedded.org) project. Started developing on monotone at the 2007 summit at Google with the net.venge.monotone.ssh-agent branch (see ["[[MonotoneAndSSHAgent]]"]). For more info: http://justin.patrin.info/ ============================================================ --- wiki/People/MarkusSchiltknecht.mdwn e7af610cd03712930184610b9509e1ec2e36a046 +++ wiki/People/MarkusSchiltknecht.mdwn e106baca0cb562129738b51fb3396a4aca33d0af @@ -8,4 +8,4 @@ personal webpage, which certainly needs personal webpage, which certainly needs some work: [http://www.bluegap.ch] +Besides monotone, I'm also working on replication solutions for [[PostgreSQL]], see [http://www.postgres-r.org] for that. -Besides monotone, I'm also working on replication solutions for PostgreSQL, see [http://www.postgres-r.org] for that. ============================================================ --- wiki/People/RichardLevitte.mdwn 9b53e2e160ffd880a10671eea7e42342c1f2d25e +++ wiki/People/RichardLevitte.mdwn d27520b1b855279a8ede6359d342778e6ada0298 @@ -11,4 +11,4 @@ I'm not on IRC very often, but I can tal I'm not on IRC very often, but I can talk a lot on the mailing lists :-) ---- +CategoryHomepage [[CategoryHomepage]] [[CategoryHomepage]] -CategoryHomepage CategoryHomepage CategoryHomepage ============================================================ --- wiki/People/User:Metaeducation.mdwn e5e1184ce3c35a0f3db5135e4eafe89d158d7444 +++ wiki/People/User:Metaeducation.mdwn c98624e401612fa72773eb4f5729c04ec8003e8a @@ -5,4 +5,4 @@ Hello there. I was a programmer for a l * see http://en.wikipedia.org/wiki/User:Metaeducation for my Wikipedia Page * see http://meta.wikimedia.org/wiki/User:Metaeducation for my thoughts on improving Wiki software) +I would not have been able to get my head around the Monotone model (at least not nearly as easily) if not for the patient+helpful people on the #monotone IRC channel, with whose help I started [[AlternativeOverview]] and [[BuildingOnMac]]. -I would not have been able to get my head around the Monotone model (at least not nearly as easily) if not for the patient+helpful people on the #monotone IRC channel, with whose help I started AlternativeOverview and BuildingOnMac. ============================================================ --- wiki/People.mdwn 58876899a68913977e94b96b5b6992b6502e5475 +++ wiki/People.mdwn c09f37c644f055d62b7f9528fe7d737b61e21c0a @@ -77,7 +77,7 @@ This page will introduce some of the mem * author of [Iara](http://www.ventonegro.org/iara/) monotone web-frontend * contact: address@hidden, http://www.ventonegro.org/ -### Matthew Nicholson (man, matthew_i, MasterYoda) +### Matthew Nicholson (man, matthew_i, [[MasterYoda]]) * uses monotone since late 2005 * works on monotone since early 2006 ============================================================ --- wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn f3a16d0e6c131eb5c0ed3faa8748727bfe226054 +++ wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn 195925cb3660849f40f64a4bc4c20735b27481a0 @@ -13,7 +13,7 @@ Question on Note on Note: Can you provid ---- Question on Note on Note: Can you provide a specific monotone command (or ideally, a specific SQL statement) that is aided by ANALYZE when run on the latest monotone database complete with user/sys/real timings? - - I think 'heads' will do it, the query to select branch certs with a particular value. - MattJohnston + - I think 'heads' will do it, the query to select branch certs with a particular value. - [[MattJohnston]] ---- @@ -138,4 +138,4 @@ As a short term thing, we could try and As a short term thing, we could try and guess when a repository needs to be analyzed and print a message advising the user to do so manually. +There is some [specific discussion](http://www.sqlite.org/cvstrac/tktview?tn=1414) in the SQLite bug tracker about the interaction between analyze and monotone and also a [discussion of our general problem](http://www.sqlite.org/cvstrac/wiki?p=[[QueryPlans]]) in the SQLite wiki. We should probably consider experimenting with some of the suggested changes to see if we can get away from a dependence on analyze for decent performance. -There is some [specific discussion](http://www.sqlite.org/cvstrac/tktview?tn=1414) in the SQLite bug tracker about the interaction between analyze and monotone and also a [discussion of our general problem](http://www.sqlite.org/cvstrac/wiki?p=QueryPlans) in the SQLite wiki. We should probably consider experimenting with some of the suggested changes to see if we can get away from a dependence on analyze for decent performance. ============================================================ --- wiki/PerformanceWork.mdwn 324a5452ba0f3f4b204b0f95174ab988c3f81bca +++ wiki/PerformanceWork.mdwn 576077e6dc883da277d04218ea0952e0d2a6cd3f @@ -31,7 +31,7 @@ Updating a large tree sometimes seems to Updating a large tree sometimes seems to take a good amount of time on a large tree and/or workspace. Finding the branch and revision to update seems to take an inordinate amount of time. - "mtn up" on an OpenEmbedded database can take 80s or more to output "updating along branch xxx". That seems an awfully long time to figure out the branch of the current checkout. Selecting the output target and actually updating was 5-10s more. During the initial 80s my CPU was mostly waiting for IO so it seems most if not all of the 100MB DB was being read into memory. + "mtn up" on an [[OpenEmbedded]] database can take 80s or more to output "updating along branch xxx". That seems an awfully long time to figure out the branch of the current checkout. Selecting the output target and actually updating was 5-10s more. During the initial 80s my CPU was mostly waiting for IO so it seems most if not all of the 100MB DB was being read into memory. This has been traced to a number of sources, and should have improved **significantly** in monotone 0.30. @@ -47,7 +47,7 @@ This has been traced to a number of sour # SQLite -See ["PerformanceWork/SQLiteAnalyzeDiscussion"]. +See ["[[PerformanceWork]]/SQLiteAnalyzeDiscussion"]. # Automated Performance Test Suite ============================================================ --- wiki/ReleaseBranchPattern.mdwn 106f65ca6e1015c801912df7abfd294c00217b4a +++ wiki/ReleaseBranchPattern.mdwn a0ca8cd2da2ba5a6225b56628164cbdebd662b35 @@ -6,7 +6,7 @@ ### How to Use - Create a working branch 'com.example.foo' using the VendorBranchPattern. Pick the revisions of the sub-branches that you want to deliver, and merge them into your work branch. + Create a working branch 'com.example.foo' using the [[VendorBranchPattern]]. Pick the revisions of the sub-branches that you want to deliver, and merge them into your work branch. Create a branch off of your work branch that you will deliver 'com.example.foo.deliverables' (a simple way of doing this is to commit with the --branch option) @@ -16,8 +16,8 @@ ### NOTES - * if one of the sub-branches added a file to a directory that was dropped in the 'example.com.foo.deliverables' branch, then you'll get a non merge conflict when you do the propagate. These are a pain to solve, at least until the MergeViaWorkingDir is integrated into mainline monotone. + * if one of the sub-branches added a file to a directory that was dropped in the 'example.com.foo.deliverables' branch, then you'll get a non merge conflict when you do the propagate. These are a pain to solve, at least until the [[MergeViaWorkingDir]] is integrated into mainline monotone. * you have created a release branch, and massaged the release branch to contain only what you want to deliver. Be careful not to merge or propagate from the release branch to the work branch. Doing so would be what I call an ["Oedipus Rex"](http://en.wikipedia.org/wiki/Oedipus_rex) merge -- it will propagate all of the massaging you did on the release branch back to the work branch. In this pattern, release branches are not intended to be merged back to trunk. + * ''DC: I don't think the content of this page describes what I would think of as a release branch. It sounds to me more like something I'd call an [[IntegrationBranch]] or and [[AssemblyBranch]], and seems to be more about using merge_into_dir than about the branch itself. That doesn't mean it's bad or wrong, I just think its in the wrong place... My view of what a release branch means is something similar to what's shown on http://www.netbsd.org/Releases/release-map.html, and that's the meaning I used when talking about release branches in the [[DaggyFixes]] page. - * ''DC: I don't think the content of this page describes what I would think of as a release branch. It sounds to me more like something I'd call an IntegrationBranch or and AssemblyBranch, and seems to be more about using merge_into_dir than about the branch itself. That doesn't mean it's bad or wrong, I just think its in the wrong place... My view of what a release branch means is something similar to what's shown on http://www.netbsd.org/Releases/release-map.html, and that's the meaning I used when talking about release branches in the DaggyFixes page. ============================================================ --- wiki/RevertUI.mdwn 4324d897baf2c4a502cdc88309f531a57ef87d85 +++ wiki/RevertUI.mdwn 4cc6065ac29149c10c25ca1e584104d080c2518a @@ -10,7 +10,7 @@ People have complained that the current # Ideas * List what we are doing, similar to `update`. This seems like a no-brainer. - * Add undo support. This is complex, but a seriously good idea in any case -- revert and update are both dangerous commands, and dangerous is bad. This would seem to totally fix the first 2 issues above; even if you occasionally run `monotone revert` by accident on the wrong thing, it only takes a second to get back to where you were. See WorkingCopyUndo. + * Add undo support. This is complex, but a seriously good idea in any case -- revert and update are both dangerous commands, and dangerous is bad. This would seem to totally fix the first 2 issues above; even if you occasionally run `monotone revert` by accident on the wrong thing, it only takes a second to get back to where you were. See [[WorkingCopyUndo]]. * Add an option to say "yes, I mean everything". So, for instance, `monotone revert --all` and `monotone revert foo/bar.txt` would be legal commands, but `monotone revert` would not be. The idea isn't so much to make the user think ahead, because users just get muscle memory for the special option and you end up accomplishing nothing (cf. `rm -f`). But, there is still an argument for this because it * prevents new users from making mistakes * stops _accidental_ runs in experienced users, by increasing the distance between what they wanted and what would delete all their work. (Of course, one could still type `monotone revert src` when one wanted `monotone revert src/Makefile`.) ============================================================ --- wiki/RostersTodo.mdwn bedeefc2da76f173cbbdc00bff1e4c46a5f7c79e +++ wiki/RostersTodo.mdwn a123e3feb2dad659d01eb758158d6e205b797c10 @@ -27,7 +27,7 @@ There is a mailing list post by NJS expl * cset reading tests * detect non-normalized-whitespace-ness - tricky, requires teaching the parser about whitespace ?? * test equal_up_to_renumbering - * RostersTodo/MarkAndMergeTests + * [[RostersTodo]]/MarkAndMergeTests # Smaller tweaks: @@ -47,5 +47,5 @@ There is a mailing list post by NJS expl # Deferred - * MergeViaWorkingDir + * [[MergeViaWorkingDir]] * git_import (unless pasky wakes up and tells us what's going on with it) ============================================================ --- wiki/SimplerIgnoreMechanism.mdwn d96b82bec9cc7525a07f5f2a9439dd0549202671 +++ wiki/SimplerIgnoreMechanism.mdwn a1cb5e03e5b348616ea479167714e3eb10e987f2 @@ -61,7 +61,7 @@ Documented at http://svnbook.red-bean.co Documented at http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.ignore.html. This is the only one that doesn't use a file. The `svn:ignore` property on a versioned directory specifies a list of glob patterns to be matched against basenames of files *in that directory only*. (In practice, people have the same or nearly the same `svn:ignore` property on all their directories.) There is also a per-user "ignore basenames matching all these globs always" pattern. -The manual is at pains to point out that the ignore property does not affect treatment of files already under version control. Apparently a lot of Subversion users are confused and think that if a versioned file matches an ignore glob, changes to it won't be committed unless specially requested. I don't know how anyone could get that idea - does Visual SourceSafe work that way or something? +The manual is at pains to point out that the ignore property does not affect treatment of files already under version control. Apparently a lot of Subversion users are confused and think that if a versioned file matches an ignore glob, changes to it won't be committed unless specially requested. I don't know how anyone could get that idea - does Visual [[SourceSafe]] work that way or something? ### codeville ============================================================ --- wiki/SummerOfCode/2006.mdwn 26c9465aa9acb5c1656d5ad260e24b2260751978 +++ wiki/SummerOfCode/2006.mdwn a7d294e9ec6d3aebbe25421ca6b61a1e7fdc1c22 @@ -38,13 +38,13 @@ Here are some example ideas for projects Here are some example ideas for projects. Feel free to suggest others. ### Largish projects - * MergeViaWorkingDir: This has been a number-1 requested feature for ages and ages. + * [[MergeViaWorkingDir]]: This has been a number-1 requested feature for ages and ages. Since the release of v0.26 this month, it is now reasonably straightforward to implement! This will involve getting nice and dirty with monotone internals, the details of how merging works, and have lots of crunchy UI questions too. I envision someone doing this having a basic working prototype merged into mainline in a few weeks to start getting user feedback, and then working on polishing the UI, or adding cool new things like - NonMergeConflicts. + [[NonMergeConflicts]]. * Create a performance test harness, and benchmarks using it. This would be _extremely_ valuable for tuning monotone's speed, testing changes, and catching performance regressions. There are more details [here](http://venge.net/monotone/wiki/PerformanceWork#head-150324c5862f1b409230043ade62a5041c227400). @@ -64,7 +64,7 @@ Here are some example ideas for projects ### Smaller projects "Buy two, they're cheap" - * MagicSelectors: enhancing the monotone command line + * [[MagicSelectors]]: enhancing the monotone command line * Add symlink support to monotone * Teach monotone to use ssh-agent to store keys * Add a way to specify "templates" for [mtn automate](http://venge.net/monotone/docs/Scripting.html) @@ -107,7 +107,7 @@ anyway: with monotone already to do in a summer, but throwing them out there anyway: - * File revival -- see HistoryBlueSky + * File revival -- see [[HistoryBlueSky]] * "partial pull" -- fetching only a portion of history into a local database, for projects that have a lot of history. * SPKI-inspired naming and trust delegation. This is an area of active work for @@ -120,7 +120,7 @@ A few funky things, that are not *strict (network stuff, signals, etc.); several of the things on the list above would be greatly helped by this. Chryn is a half-working prototype of a general async IO library for C++. - * "Hedg": A mad idea of NathanielSmith's for how to build a better + * "Hedg": A mad idea of [[NathanielSmith]]'s for how to build a better project management system, similar to Trac but with extra coolness. Talk to him if curious about details... ============================================================ --- wiki/SummerOfCode/2007/Ideas.mdwn 64856bff66cddcd2c9d5eee8ad9e69cdba6a50fa +++ wiki/SummerOfCode/2007/Ideas.mdwn 420b0d4122e6423d940b7a1dc5057e4123db03bc @@ -1,8 +1,8 @@ [[!tag migration-auto]] # Ideas for the Google Summer Of Code 2007 -Main page: SummerOfCode2007 +Main page: [[SummerOfCode2007]] ## monotone @@ -24,7 +24,7 @@ Main page: SummerOfCode2007 * make netsync startup fast * redo windows pipe support * synchronization over dumb protocols (e.g. HTTP, SFTP) - * LogUI + * [[LogUI]] * conflict handling * .mtn-ignore cleanup -- globbing, move into C++ code (currently handled in lua) * unified workspace scan caching ============================================================ --- wiki/TestHarnessIssues.mdwn cd9b9a7720dbdb6e0472f5168e60cbf25d9a0361 +++ wiki/TestHarnessIssues.mdwn 153db3af1cd0c7e848debf5d930bda42c9e849a1 @@ -13,4 +13,4 @@ The lua-based test harness is pretty nic * Some way of re-running all **failed** tests would be good ---- +See also [[OldTestHarnessIssues]] from the days of autotest. -See also OldTestHarnessIssues from the days of autotest. ============================================================ --- wiki/Testimonials.mdwn 9dfd1492338cfeb6ae268de8dde2a3cd02bc509c +++ wiki/Testimonials.mdwn 2a2c6e7300169f7cd5ee894560a3677e55c300ec @@ -8,7 +8,7 @@ Tell us what you really think. * "I've spent some 6 years searching for the perfect replacement for CVS. Many current replacements were either crap or too complex for me to understand. Monotone came as a breath of fresh air, with a few powerful and stable principles and ideas, and yet simple enough to understand by just reading one chapter in the manual! I love the distributed concept, the clearly defined off-line commits and the way the history graph is kept, and am currently moving everything I have to monotone." -- [Richard Levitte](http://richard.levitte.org), 2005-11-02 - * "Monotone rocks!" -- MatthewNicholson + * "Monotone rocks!" -- [[MatthewNicholson]] * It's a real pleasure to work with monotone, both the product and the people. Apart from the obvious advantages of distributed revision control i've been looking forward to become more widely available in free software, the team also shows they care about the right things. This is both from a technical point of view (sometimes called *paranoia*) but also showing an interest in the problems encountered in daily work for the projects using monotone. The advantage (and necessity) for a scm to be open source has become very clear to me again. -- Marcel van der Boom ============================================================ --- wiki/TrustFoundations.mdwn 3fb83b250596d7f4bc8517a43b7af17ea7d79e8e +++ wiki/TrustFoundations.mdwn 6f4b798cbcbac05d9cb61bd81e1a3df4126131d0 @@ -9,7 +9,7 @@ revision: membership of a branch, fitnes that revision, and its fixed ancestry. Certs are issued and signed by developer keys, and each cert makes some kind of assertion about a revision: membership of a branch, fitness for a particular purpose, -passing a particular QA test, etc. See UsingCerts for examples of +passing a particular QA test, etc. See [[UsingCerts]] for examples of standard assertions that are commonly made about revisions. ## Trusted Revisions @@ -110,5 +110,5 @@ Mechanisms to automate this, and allow d seed). Mechanisms to automate this, and allow delegation to a -'project authority' for common VersionedPolicy statements that affect trust +'project authority' for common [[VersionedPolicy]] statements that affect trust evaluation are the next major development focus. ============================================================ --- wiki/UsingCerts.mdwn 6d8aeb0974e5b0765949d7a482b21042dbf1b700 +++ wiki/UsingCerts.mdwn 9a6db131928b337840348625d6509b5ac0cff12e @@ -1,6 +1,6 @@ [[!tag migration-auto]] -Monotone stores important information about revisions in certs. This page descibes how some of the common certs are used in practice; you can also define your own CustomCerts for your own purposes. +Monotone stores important information about revisions in certs. This page descibes how some of the common certs are used in practice; you can also define your own [[CustomCerts]] for your own purposes. The normal certs that go with just about all revisions are *branch*, *author*, *date* and *changelog*. There can be multiples of any of these, @@ -29,8 +29,8 @@ the value (eg, branch name), so you can Trust is determined by the signer of the *branch* cert (rather than the value of the author cert), the name of the cert (eg, "branch"), and the value (eg, branch name), so you can configure trusts differently -for different branches. See TrustFoundations for more -discussion about how trusts based on certs work, and the BranchAnalogy for more about the meaning +for different branches. See [[TrustFoundations]] for more +discussion about how trusts based on certs work, and the [[BranchAnalogy]] for more about the meaning and interpretation of branch membership in monotone, as compared to other systems. Because *branch* certs can be applied after the fact, it's possible to @@ -39,7 +39,7 @@ it fit for that purpose, for example (se fitness. I might require three release-engineering members all to attest that a revision belongs on the super-stable release branch, before I consider it fit for that purpose, for example (see below for another variant of -this). Take a look at the DaggyFixes page for +this). Take a look at the [[DaggyFixes]] page for examples of using `approve` to bless previously committed revisions onto another branch. @@ -130,7 +130,7 @@ escaped into the wild, you have either a server next time they `sync`, so you'll also have to convince them to delete the item(s) too. So once the information you want to destroy has escaped into the wild, you have either a difficult chase or some -careful persuading to do. BranchRenaming illustrates this process, and +careful persuading to do. [[BranchRenaming]] illustrates this process, and some of these difficulties, using the current form of *branch* certs; CertCleanup contains some future development notes for a more user-friendly way of handling branch (re)naming without specifically ============================================================ --- wiki/VendorBranchPattern.mdwn 6621c77ce54e638e17fd2daf3fec439b2955b094 +++ wiki/VendorBranchPattern.mdwn 0b0959b98e7b3642f2a176719f3b6ab9bc60bbd6 @@ -10,7 +10,7 @@ You can use the org.sqlite branch to pla You can use the org.sqlite branch to play around with sqlite, and when you find a new version that you want to try, you can use explicit_merge (or propagate) to bring it into com.example.foo. -Back to BestPractices. +Back to [[BestPractices]]. -------- ## Comments +''A step-by-step example would be a nice enhancement to this page and to the explaination given in the manual. A counter-example to doing nested checkouts with pro's and con's would help illustrate the benefits of merge_into_dir. -- [[ChadWalstrom]]'' -''A step-by-step example would be a nice enhancement to this page and to the explaination given in the manual. A counter-example to doing nested checkouts with pro's and con's would help illustrate the benefits of merge_into_dir. -- ChadWalstrom'' ============================================================ --- wiki/VersionedPolicy/Archive.mdwn d7636e726c27da710afc84d1b8638d3ba09878d7 +++ wiki/VersionedPolicy/Archive.mdwn 27012092392a89a692c1aa870dd9fd7272071ae9 @@ -90,9 +90,9 @@ http://article.gmane.org/gmane.comp.vers http://article.gmane.org/gmane.comp.version-control.monotone.devel/6917 ## Questions -Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (`mtn -d DATABASE -bBRANCHNAME co --policy PDIR`), or simply specify something like `-bBRANCHNAME."policy"`. Could you provide links or information on the "big picture." -- ChadWalstrom +Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (`mtn -d DATABASE -bBRANCHNAME co --policy PDIR`), or simply specify something like `-bBRANCHNAME."policy"`. Could you provide links or information on the "big picture." -- [[ChadWalstrom]] - *You plan on using a directory hierarchy...to describe policy...these branches are not working directories for your branches* -- yes, exactly right. *As another branch in the database?* -- yep again, probably with some fixed name, I guess? The exact UI beyond that I'm not sure -- certainly one thing to figure out as things settle down would be what sort of sugar is useful. I'd almost be tempted to have it automatically checked out to a subdirectory of _MTN/ or something, even, just to make things as low-impedence as possible? But this is just guessing, can't make sensible UI choices until much later in the process. -- NathanielSmith + *You plan on using a directory hierarchy...to describe policy...these branches are not working directories for your branches* -- yes, exactly right. *As another branch in the database?* -- yep again, probably with some fixed name, I guess? The exact UI beyond that I'm not sure -- certainly one thing to figure out as things settle down would be what sort of sugar is useful. I'd almost be tempted to have it automatically checked out to a subdirectory of _MTN/ or something, even, just to make things as low-impedence as possible? But this is just guessing, can't make sensible UI choices until much later in the process. -- [[NathanielSmith]] --- ============================================================ --- wiki/VersionedPolicy/Comparison.mdwn b6a4c59f8ac0e36b6c7eea617ab2a631087b2297 +++ wiki/VersionedPolicy/Comparison.mdwn abc9be888d0073c990627167283b1c76a720de9f @@ -8,7 +8,7 @@ * how to tell good revisions from bad (eg trusted keys) * "Policy branches" are versioned branches that contaiin branch descriptors * Policy branches don't have policy for themselves, only for other branches - * Here, is "other branches" == sub branches? Or could net.foo.bar contain a policy for net.foo.baz? - JackLloyd + * Here, is "other branches" == sub branches? Or could net.foo.bar contain a policy for net.foo.baz? - [[JackLloyd]] * They can have policy for other policy branches and for "normal" branches. * Policy branches can provide names for what they refer to with branch descriptors * or they can defer everything that is referred to them to another policy branch wholesale ============================================================ --- wiki/VersionedPolicy/Graydon.mdwn 12ff51ff5b3eecc4383d96cb80bcbc1460caf55c +++ wiki/VersionedPolicy/Graydon.mdwn 22266864c4af8611753ebb7eccf7ecd9bab95a2a @@ -11,8 +11,8 @@ We have a structure called a policy. Pol meta: (string, string) map; delegation: delegation; } - and delegation = SimpleDelegate of branch_policy - | FullDelegate of { content_branch: branch_policy option; + and delegation = [[SimpleDelegate]] of branch_policy + | [[FullDelegate]] of { content_branch: branch_policy option; subpolicy_branches: (string, branch_policy) map; } @@ -24,7 +24,7 @@ We have a structure called a policy. Pol and branch_status = Active | Dormant and branch_id = Root - | ChildOf(branch_id, nonce) // hashed to compress to constant size + | [[ChildOf]](branch_id, nonce) // hashed to compress to constant size and user = { pk: key_id; meta: (string,string) map; } @@ -100,4 +100,4 @@ levels of authorization and kill-switche We also include a form of delegation that exists purely for inserting extra levels of authorization and kill-switches, without introducing new branch +name components. This is a [[SimpleDelegate]]. -name components. This is a SimpleDelegate. ============================================================ --- wiki/VersionedPolicy/SPKIWontWork.mdwn e89e46058e0872a83dfb44a8b28dbe40f63ebcbb +++ wiki/VersionedPolicy/SPKIWontWork.mdwn 8ac45302e880b2029559870b06dabcff1f382d2f @@ -1,6 +1,6 @@ [[!tag migration-auto]] -This page should probably be called "SPKIWontBeEnough", since it will probably work, just not provide quite as strong a formalism as we want (if we strip clocks from it). +This page should probably be called "[[SPKIWontBeEnough]]", since it will probably work, just not provide quite as strong a formalism as we want (if we strip clocks from it). --- ============================================================ --- wiki/Win32DeviceFiles.mdwn 29e2e7aef2004f6248f86ffc9d17487d62f2f50f +++ wiki/Win32DeviceFiles.mdwn 6476a4bc2bf326de2aabd22a6bd0eadccfdf8ce0 @@ -6,7 +6,7 @@ It has happened in real use that someone It has happened in real use that someone inadverdantly tried to check out a tree containing a file named "aux", and was very confused at the problems that ensued. (Fortunately, because monotone always gives files their real names via renaming, which fails for these cases, we do not seem vulnerable to any security issues at this time. If we wrote directly to the files in question, this would not be the case.) -The solution seems to be similar to that described in CaseInsensitiveFilesystems -- if the user tries to check out such files/dirs, signal them as a name conflict. +The solution seems to be similar to that described in [[CaseInsensitiveFilesystems]] -- if the user tries to check out such files/dirs, signal them as a name conflict. Also, we should make sure that "monotone add", "monotone rename", fail for such files. ============================================================ --- wiki/ZeroConf.mdwn fd6b1785fe2b21e1e02a76996f6add0e2605004f +++ wiki/ZeroConf.mdwn 0304edd116eae392b0de0970394a36e6ac7298f0 @@ -1,6 +1,6 @@ [[!tag migration-auto]] -I was wondering if anyone has considered integrating the ZeroConf discovery protocol. For Apple fans this was known as "Rendezvous", now "Bonjour". Given monotone's ability to perform peer-to-peer syncing that it would be useful (as well as cool) to auto-discover servers for your database. +I was wondering if anyone has considered integrating the [[ZeroConf]] discovery protocol. For Apple fans this was known as "Rendezvous", now "Bonjour". Given monotone's ability to perform peer-to-peer syncing that it would be useful (as well as cool) to auto-discover servers for your database. Any interest? -jason ============================================================ --- wiki/ikiwiki_migration.mdwn a96c399e205ae0213082784115acaa97afe2102f +++ wiki/ikiwiki_migration.mdwn a39c1ff455f434a55467d7d48caeeb397c4ff541 @@ -1,23 +1,23 @@ 1. fetch the page you're going to migrat # How to migrate pages to ikiwiki 1. fetch the page you're going to migrate, in raw original moinmoin markup style, into the workspace, and commit it as is for reference. (adjust as needed for some other tool, like wget or curl). - ftp -o ZipperMerge.moin "http://www.venge.net/mtn-wiki/ZipperMerge?action=raw" - mtn add ZipperMerge.moin + ftp -o [[ZipperMerge]].moin "http://www.venge.net/mtn-wiki/ZipperMerge?action=raw" + mtn add [[ZipperMerge]].moin mtn commit Note that most pages have already been fetched en-masse; you should - only need to re-fetch if there have been changes in MoinMoin you + only need to re-fetch if there have been changes in [[MoinMoin]] you want to bring across (you can check the revision history of the page on the old wiki site). 2. rename the file and begin the process of migrating the markup: - sed -Ef moin2mdwn.sed ZipperMerge.mdwn - mtn mv --bookkeep-only ZipperMerge.moin ZipperMerge.mdwn - rm ZipperMerge.moin + sed -Ef moin2mdwn.sed <[[ZipperMerge]].moin >[[ZipperMerge]].mdwn + mtn mv --bookkeep-only [[ZipperMerge]].moin [[ZipperMerge]].mdwn + rm [[ZipperMerge]].moin (use `sed -rf` on Linux instead) @@ -43,7 +43,7 @@ 3. Translate the markup. *Some of this m of single-quotes * Links are done with `\[[SquareBrackets]]` rather than bare - `CamelCaseWords` + `[[CamelCaseWords]]` * preformatted code blocks are done with 4 more spaces (inside the current level of indentation, say when inside nested lists),