# # # patch "wiki/VersionedPolicy/Archive.mdwn" # from [0b3f880dbea80e62307b34d7ee0e97eea3d8991d] # to [ec073eb396b25fe766e8088ee16a398ed9d98298] # # patch "wiki/VersionedPolicy/Comparison.mdwn" # from [c3e848da2d388b80d9298f1f155ff978f6c2e49a] # to [723ae44abe0001fcd9c12f2023e99e33762ef5f1] # # patch "wiki/VersionedPolicy/Interface.mdwn" # from [c256685bc78e56d7623b0a340033fcc1ed1c9f57] # to [042bf5a319676d6b8e65de227584539799acfed1] # # patch "wiki/VersionedPolicy/SPKIWontWork.mdwn" # from [8ac45302e880b2029559870b06dabcff1f382d2f] # to [4bc15c27ff7a79fab409960be0b37e595418c328] # # patch "wiki/VersionedPolicy/WorkList.mdwn" # from [5d30f6c18907582cd35609e569d8176f293527d6] # to [134b415dfd1f0d6291421e004a268c5ce1c5dcd4] # ============================================================ --- wiki/VersionedPolicy/Archive.mdwn 0b3f880dbea80e62307b34d7ee0e97eea3d8991d +++ wiki/VersionedPolicy/Archive.mdwn ec073eb396b25fe766e8088ee16a398ed9d98298 @@ -1,19 +1,19 @@ -[[!tag migration-auto]] +[[!tag migration-done]] Random notes on how to version policy (fine-grained permissions, trust delegation, branch names...). # Mostly-obsolete notes of historical interest -Classic conversation on how to make permissions work at all, sketching the basic approach: http://frances.vorpus.org/~njs/mt-permission.html +Classic conversation on how to make permissions work at all, sketching the basic approach: January 2007: -http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9835/focus=9835 -http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9842/focus=9842 + + And one from Paul Crowley (February 2007): -http://thread.gmane.org/gmane.comp.version-control.monotone.devel/10077/focus=10077 + -Useful conversation from April 2006: http://colabti.de/irclogger//irclogger_log/monotone?date=2006-04-18,Tue&sel=119#l194 +Useful conversation from April 2006: Includes argument for why the right rule for evaluating whether a merge followed permission rules, is if _either_ cset is allowable by permission rules. @@ -87,12 +87,12 @@ The pastebin link (since it will probabl ## User requests -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." -- [[People/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]] +> 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. -- [[People/NathanielSmith]] --- ============================================================ --- wiki/VersionedPolicy/Comparison.mdwn c3e848da2d388b80d9298f1f155ff978f6c2e49a +++ wiki/VersionedPolicy/Comparison.mdwn 723ae44abe0001fcd9c12f2023e99e33762ef5f1 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] # Things in common between Paul's proposal and Graydon's ============================================================ --- wiki/VersionedPolicy/Interface.mdwn c256685bc78e56d7623b0a340033fcc1ed1c9f57 +++ wiki/VersionedPolicy/Interface.mdwn 042bf5a319676d6b8e65de227584539799acfed1 @@ -1,12 +1,15 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This is what the results of the policy mechanism should be, and how it should interact with the rest of the world. **Initalization** + * Required out-of-band transfers should be limited to an identifier (hash of a policy revision), or a URI to fetch an identifier. * It should be possible get a (name, identifier) list for what's available on a server. It should be possible to update this list without restarting the server. (Lua hook or db var, probably?) Of course, this list may not be exhaustive and you may not wish to trust it. + **General** + * Monotone needs to work normally with a database holding any number of projects. * It should be possible to rename branches. * It should be possible to rename keys. @@ -14,5 +17,6 @@ This is what the results of the policy m * Branches should be able to have descriptions, as well as names. **Network** + * It should probably be possible to filter incoming/outgoing data according to whether it's signed by a key known to a specified policy revision (If I won't trust it anyway, why waste bandwidth/disk space on it?). It must also be possible to turn this off. (If my project is on a shared server, I shouldn't have to be bothered with what people in other projects put on shared revisions. Unless I want to be.) * Definitely. It's more than an optimization; you don't want a bunch of warez d00dz using an alternate policy branch on your server to swap cracked games. (This has actually happened to me - ok, it was 1996, and it was an anonymous FTP server that got exploited, but hey, that's what we had in 1996.) Or, consider an organization like the FSF that requires copyright assignments; they're going to want to be sure their "official" server doesn't even look at any submissions whose bits are the wrong color. -- Zack ============================================================ --- wiki/VersionedPolicy/SPKIWontWork.mdwn 8ac45302e880b2029559870b06dabcff1f382d2f +++ wiki/VersionedPolicy/SPKIWontWork.mdwn 4bc15c27ff7a79fab409960be0b37e595418c328 @@ -1,6 +1,6 @@ -[[!tag migration-auto]] +[[!tag migration-done]] -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/VersionedPolicy/WorkList.mdwn 5d30f6c18907582cd35609e569d8176f293527d6 +++ wiki/VersionedPolicy/WorkList.mdwn 134b415dfd1f0d6291421e004a268c5ce1c5dcd4 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] * Changes to certs * Bundle author+branch+date+changelog into single cert (or N name/value pairs?)