# # # patch "wiki/AutomateWishlist.mdwn" # from [bad8350781e1b4ff7614c8e5fedb4d9a82c2adb1] # to [7bd986c014f1219ccb5022bbd56f7f3fa07823f8] # # patch "wiki/BranchNamingConventions.mdwn" # from [cf57a3f22cff7a3acc99d22398c09b9bf1938bdb] # to [3e04c38733865fdc2eefccaca65aff45ec7be240] # # patch "wiki/BranchStatuses.mdwn" # from [f81561260129684fd39a4d46f4ca57f36e64c8af] # to [bb61a755796f5be37160a23df23dade4b26283ad] # # patch "wiki/CvsImport.mdwn" # from [ef2d8c06ec67e31752a19c9a377a705394ee2c4d] # to [d262cbe2229b408f27d6781796ed61261730c598] # # patch "wiki/MonotoneOnDebian.mdwn" # from [e5923328247cbed0cfc7eb10bbc9d3269178b448] # to [3be4b421940bc6a645e02932875d9fc1caef8c5e] # # patch "wiki/MtnSummit/2007.mdwn" # from [ecb6d72631bf26b365028be2e3c941bdc53f5daf] # to [03f79ee374a2882b53a8ce6bf749f32c44c85bce] # # patch "wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn" # from [195925cb3660849f40f64a4bc4c20735b27481a0] # to [129b9b89a10e714df93779d8798102ed5db4bfe0] # # patch "wiki/VendorBranchPattern.mdwn" # from [0b0959b98e7b3642f2a176719f3b6ab9bc60bbd6] # to [5df1301f79eb01e24f3501dd2fdcab509eea7b08] # # patch "wiki/VersionedPolicy/Archive.mdwn" # from [27012092392a89a692c1aa870dd9fd7272071ae9] # to [0b3f880dbea80e62307b34d7ee0e97eea3d8991d] # # patch "wiki/VersionedPolicy/Comparison.mdwn" # from [abc9be888d0073c990627167283b1c76a720de9f] # to [c3e848da2d388b80d9298f1f155ff978f6c2e49a] # ============================================================ --- wiki/AutomateWishlist.mdwn bad8350781e1b4ff7614c8e5fedb4d9a82c2adb1 +++ wiki/AutomateWishlist.mdwn 7bd986c014f1219ccb5022bbd56f7f3fa07823f8 @@ -24,7 +24,7 @@ Missing (but useful) functions for the a ## Extensions to support Graphical User Interfaces --- [[MarcelvanderBoom]] [[DateTime(2006-06-18T18:39:06Z)]] +-- [[People/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)]] +-- [[People/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 cf57a3f22cff7a3acc99d22398c09b9bf1938bdb +++ wiki/BranchNamingConventions.mdwn 3e04c38733865fdc2eefccaca65aff45ec7be240 @@ -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). + [[People/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"], [[People/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: @@ -45,13 +45,13 @@ Example: `venge.net:monotone`, `venge.ne 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 [[People/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 [[People/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 [[People/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: [[People/RichardLevitte]] (obviously) ### Hierarchy by # @@ -59,7 +59,7 @@ The benefit of this format is that it do 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: [[People/ChadWalstrom]] ## Hierarchy by mixed separators @@ -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. + * [[People/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. + * [[People/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. + * [[People/CraigLennox]]: I favour changing as little as possible while addressing the real problem of namespace overload (which I describe at [#[[JavaStyle]] Java Style] above). This ought to be achievable without having to change the selector syntax. * ["gwk"]: Java style (I'm a Java programmer...) it's nice and easy to read and type no shift etc. * [[ExampleUser]]: I think [....] ============================================================ --- wiki/BranchStatuses.mdwn f81561260129684fd39a4d46f4ca57f36e64c8af +++ wiki/BranchStatuses.mdwn bb61a755796f5be37160a23df23dade4b26283ad @@ -120,7 +120,7 @@ Status: landed on mainline # n.v.m.partialpull and n.v.m.gaps -Contact: [[People/ChristofPetig]] and [[MarkusSchiltknecht]] respectively +Contact: [[People/ChristofPetig]] and [[People/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. ============================================================ --- wiki/CvsImport.mdwn ef2d8c06ec67e31752a19c9a377a705394ee2c4d +++ wiki/CvsImport.mdwn d262cbe2229b408f27d6781796ed61261730c598 @@ -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, [[People/MarkusSchiltknecht]] maintains an implementation in C++, with some monotone specific modifications. ## Overview ============================================================ --- wiki/MonotoneOnDebian.mdwn e5923328247cbed0cfc7eb10bbc9d3269178b448 +++ wiki/MonotoneOnDebian.mdwn 3be4b421940bc6a645e02932875d9fc1caef8c5e @@ -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? - [[People/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.mdwn ecb6d72631bf26b365028be2e3c941bdc53f5daf +++ wiki/MtnSummit/2007.mdwn 03f79ee374a2882b53a8ce6bf749f32c44c85bce @@ -42,7 +42,7 @@ You'll also want to read about [[Logisti You'll also want to read about [[LogisticsNA]], [[Schedule]], [[Rooms]] at the hotel, and [[Funding]]. -[[JackLloyd]] was coming but then he got a new job and is going to be moving to New York that week. Maybe next time! +[[People/JackLloyd]] was coming but then he got a new job and is going to be moving to New York that week. Maybe next time! # misc stuff ============================================================ --- wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn 195925cb3660849f40f64a4bc4c20735b27481a0 +++ wiki/PerformanceWork/SQLiteAnalyzeDiscussion.mdwn 129b9b89a10e714df93779d8798102ed5db4bfe0 @@ -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. - [[People/MattJohnston]] ---- ============================================================ --- wiki/VendorBranchPattern.mdwn 0b0959b98e7b3642f2a176719f3b6ab9bc60bbd6 +++ wiki/VendorBranchPattern.mdwn 5df1301f79eb01e24f3501dd2fdcab509eea7b08 @@ -13,4 +13,4 @@ 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. -- [[People/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 27012092392a89a692c1aa870dd9fd7272071ae9 +++ wiki/VersionedPolicy/Archive.mdwn 0b3f880dbea80e62307b34d7ee0e97eea3d8991d @@ -90,7 +90,7 @@ http://article.gmane.org/gmane.comp.vers http://article.gmane.org/gmane.comp.version-control.monotone.devel/6917 ## Questions -Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (`mtn -d DATABASE -bBRANCHNAME co --policy PDIR`), or simply specify something like `-bBRANCHNAME."policy"`. Could you provide links or information on the "big picture." -- [[ChadWalstrom]] +Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (`mtn -d DATABASE -bBRANCHNAME co --policy PDIR`), or simply specify something like `-bBRANCHNAME."policy"`. Could you provide links or information on the "big picture." -- [[People/ChadWalstrom]] *You plan on using a directory hierarchy...to describe policy...these branches are not working directories for your branches* -- yes, exactly right. *As another branch in the database?* -- yep again, probably with some fixed name, I guess? The exact UI beyond that I'm not sure -- certainly one thing to figure out as things settle down would be what sort of sugar is useful. I'd almost be tempted to have it automatically checked out to a subdirectory of _MTN/ or something, even, just to make things as low-impedence as possible? But this is just guessing, can't make sensible UI choices until much later in the process. -- [[NathanielSmith]] ============================================================ --- wiki/VersionedPolicy/Comparison.mdwn abc9be888d0073c990627167283b1c76a720de9f +++ wiki/VersionedPolicy/Comparison.mdwn c3e848da2d388b80d9298f1f155ff978f6c2e49a @@ -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? - [[People/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