[Monotone-devel] Re: Using monotone in a team
On Sat, 2006-12-02 at 01:49 +, Boris wrote: Hugo Cornelis wrote: Well, what I really want to do is have a mechanism that automatically distributes the necessary hooks from one central point. For sure the members of the same team need the same trust policies, local alterations not allowed. So if you want to join the team, you first have to synchronize the trust policies. This does not preclude simple cloning for private work. Perhaps the right question is, does this layer belong to monotone or not ? I guess it does not belong to monotone. As you even want to forbid developers to change trust policies I think a distributed revision control system is not what you want. What monotone does is copying data between databases. Once it is there revisions can be combined flexibly. And how they are combined depends on the local configuration (the hook functions). At least that's my understanding so far (as usual without any warranties ;). Sounds strange to me. I'd expect the trust policy and (all? some?) of the hooks to be part of the data that monotone allows copying between the databases. This raises some issues with merging branches - you'd want to merge just the code changes, and not necessarily the policy changes. Also some hooks depend on the developer environment (e.g. the messy line-ending issue), while others may need be shared by all developers (e.g., simple pre-commit verifications). So it may be necessary to have that distinction be explicit in the system somehow. Tricky as this may be to get right, this is something you'd expect every distributed version control system to address somehow... Oren Ben-Kiki ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On 12/2/06, Oren Ben-Kiki [EMAIL PROTECTED] wrote: On Sat, 2006-12-02 at 01:49 +, Boris wrote: Hugo Cornelis wrote: Well, what I really want to do is have a mechanism that automatically distributes the necessary hooks from one central point. For sure the members of the same team need the same trust policies, local alterations not allowed. So if you want to join the team, you first have to synchronize the trust policies. This does not preclude simple cloning for private work. Perhaps the right question is, does this layer belong to monotone or not ? I guess it does not belong to monotone. As you even want to forbid developers to change trust policies I think a distributed revision control system is not what you want. What monotone does is copying data between databases. Once it is there revisions can be combined flexibly. And how they are combined depends on the local configuration (the hook functions). At least that's my understanding so far (as usual without any warranties ;). Sounds strange to me. I'd expect the trust policy and (all? some?) of the hooks to be part of the data that monotone allows copying between the databases. This raises some issues with merging branches - you'd want to merge just the code changes, and not necessarily the policy changes. Also some hooks depend on the developer environment (e.g. the messy line-ending issue), while others may need be shared by all developers (e.g., simple pre-commit verifications). So it may be necessary to have that distinction be explicit in the system somehow. Tricky as this may be to get right, this is something you'd expect every distributed version control system to address somehow... Lets talk about monotone proper (version control) and monotone add-ons (trust-policies and others, essentially everything that is project configuration for monotone proper). The following was a result of a small brain storm. Then, I guess, a checkout, can first trigger a hook, hard coded in monotone proper that first obtains a monotone add-ons database, perhaps after a round of pulling from other repositories to assemble a right local database (so here is an assumption that the other repositories are known somehow). Second, lets assume that the add-ons database contains various tags or branches, reflecting various operating systems, line ending policies and project policies (so assume that the tag names are known a priori, e.g. i386-linux-gnu). Third, these branches are merged according to the local operating system tag, line ending policy tag and project policy tag, as far as allowed (a good config design can differentiate between local and global settings, even after a merge). Fourth, the project code is checked out, and the local configuration is applied (running the Lua hooks ao). Fifth, the code is ready to be edited. I am not sure if this all makes sense, it sounds difficult and complicated at the same time to me. I think it is best to separate such issues from monotone proper, functionally and technically. Hugo -- Hugo Cornelis Ph.D. Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Using monotone in a team
Oren Ben-Kiki wrote: [...] I guess it does not belong to monotone. As you even want to forbid developers to change trust policies I think a distributed revision control system is not what you want. What monotone does is copying data between databases. Once it is there revisions can be combined flexibly. And how they are combined depends on the local configuration (the hook functions). At least that's my understanding so far (as usual without any warranties ;). Sounds strange to me. I'd expect the trust policy and (all? some?) of the hooks to be part of the data that monotone allows copying between the databases. I can't comment on this. The answer probably depends on the motives why monotone was created and what kind of problems the original developers faced with other revision control systems. There is an introduction at http://venge.net/monotone/ and some information in the FAQ. However it is not clear to me what the key features are and what other features were simply developed to support the key features. If I read for example the answer to What is the networking protocol? in the FAQ I'm not sure if netsync as it looks like today is a key feature of monotone. If it is then copying trust policies around does not belong to monotone. If it is not then monotone could be changed indeed. Is there any document which says what the explicit goals of monotone are? Boris [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
Oren == Oren Ben-Kiki [EMAIL PROTECTED] writes: Oren Sounds strange to me. I'd expect the trust policy and (all? Oren some?) of the hooks to be part of the data that monotone Oren allows copying between the databases. You have to be very careful about putting hooks directly into the monotone repository. If there is any chance that checking out a working directory from a repository means monotone will automatically execute untrusted code, then this could be very bad. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On Thu, Nov 30, 2006 at 12:24:27AM -0600, Timothy Brownawell wrote: On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote: Daniel == Daniel Carosone [EMAIL PROTECTED] writes: Daniel Again, it's not about permissions to change things, it's Daniel about whether your trust (ie, how you pay attention to) Daniel what they do. Daniel In this context, this means that everyone accepts changes Daniel in the junior branch from junior and denior developers, Daniel and in the main branch only from the senior developers. Daniel More specifically, that I only trust main-branch certs Daniel signed by senior developers. Daniel From time to time, a senior developer looks at revs in the Daniel junior branch. What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Define new (monotone has no concept of time). Except for a partial order of revisions after other revisions. You could still give a list of recent valid revisions and let the partial order fend a lot of older revisions whose certs would also be valid. The only way we really have is to take some other key (quite possibly specially generated for this, and then never used again), and reproduce all the certs that you do want to trust. (Well, you *could* give the trust hooks a list of all the known-good certs, but that gets really ridiculous really fast.) Hmm. Need to think about this more. Having every certificate contain a time and date stamp would be a good start - but then you have to trust the computer clock that creates every signature. Which has historically been enough for us to discard this idea as unworkable. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On Thu, 2006-11-30 at 11:32 -0500, [EMAIL PROTECTED] wrote: On Thu, Nov 30, 2006 at 12:24:27AM -0600, Timothy Brownawell wrote: On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote: Daniel == Daniel Carosone [EMAIL PROTECTED] writes: Daniel Again, it's not about permissions to change things, it's Daniel about whether your trust (ie, how you pay attention to) Daniel what they do. Daniel In this context, this means that everyone accepts changes Daniel in the junior branch from junior and denior developers, Daniel and in the main branch only from the senior developers. Daniel More specifically, that I only trust main-branch certs Daniel signed by senior developers. Daniel From time to time, a senior developer looks at revs in the Daniel junior branch. What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Define new (monotone has no concept of time). Except for a partial order of revisions after other revisions. You could still give a list of recent valid revisions and let the partial order fend a lot of older revisions whose certs would also be valid. But certs can be added to revisions at any time. So even if a revision is known to have been committed before the key was revoked, it's entirely possible that some certs attached to it could have been added after the key was revoked. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On Thu, Nov 30, 2006 at 10:49:25AM -0600, Timothy Brownawell wrote: On Thu, 2006-11-30 at 11:32 -0500, [EMAIL PROTECTED] wrote: On Thu, Nov 30, 2006 at 12:24:27AM -0600, Timothy Brownawell wrote: On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote: Daniel == Daniel Carosone [EMAIL PROTECTED] writes: Daniel Again, it's not about permissions to change things, it's Daniel about whether your trust (ie, how you pay attention to) Daniel what they do. Daniel In this context, this means that everyone accepts changes Daniel in the junior branch from junior and denior developers, Daniel and in the main branch only from the senior developers. Daniel More specifically, that I only trust main-branch certs Daniel signed by senior developers. Daniel From time to time, a senior developer looks at revs in the Daniel junior branch. What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Define new (monotone has no concept of time). Except for a partial order of revisions after other revisions. You could still give a list of recent valid revisions and let the partial order fend a lot of older revisions whose certs would also be valid. But certs can be added to revisions at any time. So even if a revision is known to have been committed before the key was revoked, it's entirely possible that some certs attached to it could have been added after the key was revoked. You're right ... so the best we can do is for each repository/server to remember when it first heard of each cert. In general, this will be diferent for different servers so we wouldn't want to pass this information around on a sync. In fact, if we don's trust clocks to be monotonic, we could arbitrarily but monotonically number them. Then someone on any one particular server could identify certs which were reliably old and recertify those. Recertification sould spread via sync. But it's getting complicated. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Using monotone in a team
Hugo Cornelis wrote: I did not see such a thing like 'certs' with other version control systems (I could obviously be wrong on this), but, because certs allow for many different types of user defined workflows, it is exactly the reason why I started using monotone. There is a learning curve involved when dealing with certs, because they come in handy at different places, and, as it seems, sometimes fit different functions. For the moment the wiki comes through as a bit 'theoretical'. I think it might be useful if the wiki contains more examples of how to setup things like the (almost hierarchical) work-flows explained below. I read TrustFoundations in the Wiki. And while I think I understand what it talks about I agree it's a bit theoretical. Maybe someone can tell me what I actually need to enter on the command line when we look at an example: Jim's company has been growing due to the success of JuiceBot. More developers joined his team to work on new versions of JuiceBot. The flat hierarchy in the earlier days of the company changed: Now there are junior and senior developers. While he doesn't mind senior developers to mess around in the code he doesn't want junior developers to change code in the main branch. He wants changes of junior developers to be approved by senior developers. Jim creates a new branch for junior developers: mtn --branch=jp.co.juicebot.jb7.junior --message=junior branch Then he changes the file read-permissions to: pattern jp.co.juicebot.jb7* allow [EMAIL PROTECTED] pattern jp.co.juicebot.jb7.junior* allow [EMAIL PROTECTED] Question: There is no way (and I assume no need) to set write-permissions per user? I don't see anything in the documentation that I can use pattern and allow in write-permissions, too? Now junior developers work on their own branch while senior developers can change code in the main branch directly. From time to time a senior developer checks the junior branch. 1) Let's say everything is all right. He can then propagate changes from the junior to the main branch and vice versa? 2) Let's say the senior developer doesn't like the last revision. Then he can disapprove it and revert it to the previous revision? 3) Let's say he uses the approve command which adds a certificate to the revision. How exactly can this new certificate be used? I especially wonder about option #3. Is there some automatic support for approvals or is this something which must be implemented in hook functions? Boris [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
Boris == Boris [EMAIL PROTECTED] writes: Boris Question: There is no way (and I assume no need) to set Boris write-permissions per user? I don't see anything in the Boris documentation that I can use pattern and allow in Boris write-permissions, too? I would assume you would need to do this, for each user, by overriding the get_revision_cert_trust hook. If multiple users have different projects with different policies, this could get awkward. I think there is a proposal to solve this issue, if I got to the bottom of http://www.venge.net/monotone/wiki/TrustFoundations I see: Mechanisms to automate this, and allow delegation to a 'project authority' for common VersionedPolicy statements that affect trust evaluation are the next major development focus. If I click on the link to http://www.venge.net/monotone/wiki/VersionedPolicy though, I get lost. Boris Now junior developers work on their own branch while senior Boris developers can change code in the main branch Boris directly. From time to time a senior developer checks the Boris junior branch. Boris 1) Let's say everything is all right. He can then propagate Boris changes from the junior to the main branch and vice versa? Boris 2) Let's say the senior developer doesn't like the last Boris revision. Then he can disapprove it and revert it to the Boris previous revision? 3) Let's say he uses the approve Boris command which adds a certificate to the revision. How Boris exactly can this new certificate be used? Boris I especially wonder about option #3. Is there some Boris automatic support for approvals or is this something which Boris must be implemented in hook functions? I believe the get_revision_cert_trust does this. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
Daniel == Daniel Carosone [EMAIL PROTECTED] writes: Daniel Again, it's not about permissions to change things, it's Daniel about whether your trust (ie, how you pay attention to) Daniel what they do. Daniel In this context, this means that everyone accepts changes Daniel in the junior branch from junior and denior developers, Daniel and in the main branch only from the senior developers. Daniel More specifically, that I only trust main-branch certs Daniel signed by senior developers. Daniel From time to time, a senior developer looks at revs in the Daniel junior branch. What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Hmm. Need to think about this more. Having every certificate contain a time and date stamp would be a good start - but then you have to trust the computer clock that creates every signature. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote: Daniel == Daniel Carosone [EMAIL PROTECTED] writes: Daniel Again, it's not about permissions to change things, it's Daniel about whether your trust (ie, how you pay attention to) Daniel what they do. Daniel In this context, this means that everyone accepts changes Daniel in the junior branch from junior and denior developers, Daniel and in the main branch only from the senior developers. Daniel More specifically, that I only trust main-branch certs Daniel signed by senior developers. Daniel From time to time, a senior developer looks at revs in the Daniel junior branch. What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Define new (monotone has no concept of time). The only way we really have is to take some other key (quite possibly specially generated for this, and then never used again), and reproduce all the certs that you do want to trust. (Well, you *could* give the trust hooks a list of all the known-good certs, but that gets really ridiculous really fast.) Hmm. Need to think about this more. Having every certificate contain a time and date stamp would be a good start - but then you have to trust the computer clock that creates every signature. Which has historically been enough for us to discard this idea as unworkable. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Using monotone in a team
On Thu, Nov 30, 2006 at 12:24:27AM -0600, Timothy Brownawell wrote: On Thu, 2006-11-30 at 17:06 +1100, Brian May wrote: What happens if a trusted developer's key becomes compromised (e.g. laptop stolen) or the developer becomes untrustworthy (e.g. fired)? Can you somehow say that old signatures are still valid, but new ones aren't? Define new (monotone has no concept of time). The only way we really have is to take some other key (quite possibly specially generated for this, and then never used again), and reproduce all the certs that you do want to trust. (Well, you *could* give the trust hooks a list of all the known-good certs, but that gets really ridiculous really fast.) The other way I know of is that when you revoke a key, you write down a list of all the certs you want to continue trusting. (Similarly to how when you grant trust to a key, you may want to write down a list of all the old certs that you don't want to start trusting.) So trust rules take the form of a default trust/don't trust setting, plus an explicit list of exceptions. -- Nathaniel -- But suppose I am not willing to claim that. For in fact pianos are heavy, and very few persons can carry a piano all by themselves. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
