# # # delete "wiki/CustomCerts.mdwn" # # patch "wiki/OldTestHarnessIssues.mdwn" # from [3207f9ef37b730ca836db37c53e510500d31b60f] # to [132185d71c91ba6da63ec1bb51c6f0a0fbe7fc4f] # # patch "wiki/OneBranchPerDbForServe.mdwn" # from [abc9d5fe21634c8b778dc345851e9b9b622ad7e9] # to [b5c1a47f8561abf89a7f8d2d1b0c6d2d811d27ec] # # patch "wiki/UsingCerts.mdwn" # from [9a6db131928b337840348625d6509b5ac0cff12e] # to [a53ddd31cdd0fb627ba31d8a38423cc1e4298755] # # patch "wiki/wiki-cleanup-list.mdwn" # from [60c2b01d80001c22a2f990a45c4cb42325d7385f] # to [5bb42ddfdb92566612e911997aa1f8c2914d818d] # ============================================================ --- wiki/OldTestHarnessIssues.mdwn 3207f9ef37b730ca836db37c53e510500d31b60f +++ wiki/OldTestHarnessIssues.mdwn 132185d71c91ba6da63ec1bb51c6f0a0fbe7fc4f @@ -1,12 +1,14 @@ -[[!tag migration-auto]] +[[!tag migration-done]] Nice things about autotest: + * every test gets run in its own little scratch directory * we can poke around in these scratch directories and re-run command by hand when debugging * verbose every-command-executed-and-its-output logging * can easily run commands, give stdin, get stdout, get stderr, get exit code, do basic unixy things like mkdir, run commands in subdirs, etc. Things we want: + * tests have names. none of this weird numbers in output, filenames on disk, need tools to convert between them. * proper process handling. start a netsync server, keep a handle on the process, kill it when test is done (whether success or failure) * better expectation stuff. "the thing I expected happened (which is good)" = pass, "the thing I expected happened (which is bad)" = known bug, "something weird happened" = user needs to look. autotest collapses the last two, which leads to testrot. be nice if there were better ways to record what desired behavior ir -- "I think this value will be equal to that one, but I'd rather it was equal to this third one"? ============================================================ --- wiki/OneBranchPerDbForServe.mdwn abc9d5fe21634c8b778dc345851e9b9b622ad7e9 +++ wiki/OneBranchPerDbForServe.mdwn b5c1a47f8561abf89a7f8d2d1b0c6d2d811d27ec @@ -1,11 +1,12 @@ -[[!tag migration-auto]] +[[!tag migration-done]] If you have a lot of big branches (maybe you need to version control a library of some sort), you can get a large db file. sqlite and monotone are paranoid about data integrity, but it is possible that a hardware failure during an operation can hose parts of the database. It is better to have a db file for each branch, and use Usher (net.venge.monotone.contrib.usher) to proxy connections to a server running for each branch. -==== Note about usher ==== +## Note about usher Depending on how usher is used, you may or may not have a surprise. If you configure it with each database being served by separate virtual hosts, you're absolutely safe. However, if you configure it with each database being served by branch patterns, the users will have to make sure not to try to get several collections at once. For example, the following will get the contents of first or last (depending on usher version, IIRC) configured database and nothing more: + mtn pull *yourhost* "*" + - mtn pull *yourhost* "*" ============================================================ --- wiki/UsingCerts.mdwn 9a6db131928b337840348625d6509b5ac0cff12e +++ wiki/UsingCerts.mdwn a53ddd31cdd0fb627ba31d8a38423cc1e4298755 @@ -1,7 +1,10 @@ [[!tag migration-auto]] +[[!toc levels=2]] -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. +# Certs used with monotone + The normal certs that go with just about all revisions are *branch*, *author*, *date* and *changelog*. There can be multiples of any of these, and commonly there will be if two authors have independently merged @@ -45,7 +48,6 @@ examples of using `approve` to bless pre ## *testresult* certs - The other cert that's important in most of the same cases as above is the *testresult* cert. Each test is a separate key, given to the (usually automated) testing system, which publishes "pass" or "fail" results by @@ -88,6 +90,15 @@ obvious thing: attaches a symbolic name mostly only looked at by humans. There's also a *tag* cert that does the obvious thing: attaches a symbolic name to the revision. +## custom certs + +The cert names described above are just a start. Certs are intended as an extendable way to store metadata about revisions. Some people even use them for this! Here are some interesting uses: + + * Xaraya uses them to track branch descriptions and status -- latest cert on a branch wins. + * bug fixes and shipping to clients: (not clear if these examples are real or made up?) + +# Using monotone with Certs + ## certs and selectors Apart from their simple informational value, for all of these, but ============================================================ --- wiki/wiki-cleanup-list.mdwn 60c2b01d80001c22a2f990a45c4cb42325d7385f +++ wiki/wiki-cleanup-list.mdwn 5bb42ddfdb92566612e911997aa1f8c2914d818d @@ -11,9 +11,6 @@ page - what do you think?) things which have been accomplished already and start a general "Ideas" page - what do you think?) -### CustomCerts -content should be moved into UsingCerts - ### CvsSync should be removed, renaming CvsSync3 to CvsSync?