|From:||K. Richard Pixley|
|Subject:||Re: [Monotone-devel] newbie question - SHA1 vs serials|
|Date:||Tue, 19 Apr 2005 12:39:41 -0700|
|User-agent:||Mozilla Thunderbird 1.0.2 (Macintosh/20050317)|
Richard Levitte - VMS Whacker wrote:
Situation A: Intellectual property. My company has a policy wherein all work must be done on company machines on company sites. I want to allow public key access within the company, but none others. Note that company does have remote sites. As sits, I can't use monotone to accept company changes while rejecting changes those same users might attempt to make from home. I can do this with firewalls and such, if I have access to them, but not with monotone.In message <address@hidden> on Tue, 19 Apr 2005 09:50:57 -0700, "K. Richard Pixley" <address@hidden> said: rich> As I read the manual, (the sum of my monotone experience), rich> monotone is currently vulnerable to these problems already. And rich> finding a means of addressing it would seem to be a welcome rich> addition in any case. I'm curious. Do you mind diving into this part?
Situation B: Compromised keys. If you jack my laptop, my company is hosed. We need a more interactive authentication mechanism to resolve this problem, I think.
Situation C: I'm part of a Big Company and Big Company has significant investments in ldap already. We're not willing to implement another project wherein we educate all 10 million of our employees in public/private key encryption, assign and distribute the keys to all 10 million+ repositories. Instead, we want to leverage our existing authentication mechanisms. And since we're a closed system, we can do that fairly simply, provided that we can authenticate the machines involved, (tls, kerberos, or whatever).
I think there are some others, like flooding problems, but I don't yet understand how revisions propogate well enough to name them.
Eg, if my respository accepts changes from Bob & Carol, I sync to you, but your repository only accepts changes from Bob, not Carol, then what happens to Carol's changes? What happens when Bob's latest change is a revision of one of Carol's?
Heard. I'm not coming from the common RCS perspective, or even the CVS perspective. I was a CVS developer for several years back in the early 90's after spending a decade building RCS+make based source code control systems.rich> >You have seen what history can look like with the multi-head rich> >model monotone uses, have you? rich> > rich> I can imagine it without any difficulty, yes. It'll give most rich> developers I've ever supported headaches and nightmares and rich> would likely be the biggest barrier to adoption. That's an interesting statement, and I assume you speak for yourself. When I started with monotone, I found this multi-head feature a breath of fresh air, because it means I don't need to constantly update and possibly having my own work destroyed because some other person needed to work in the same place in the source. Instead, I can calmly work on my stuff and commit it, then (when my changes are safe in the repository) I can work on merging what I have committed with the stuff coming from everyone else. I can still revert if need be. I have had no problems with it since I started using monotone (I've used monotone since something like september last year). Simply put, I don't share your sentiment.
I'm coming from the perspective of a recent clearcase professional where I have much more control over branches, users, authentication, and the like, on a much finer grain, which are all necessary because I'm reporting to management critters who are often quite paranoid about how those nasty developers are going to destabilize their precious code.
I completely understand that the automatic forking in the repository is a lovely feature. I completely understand that the ability to allow overnight background syncing without necessarily forcing merges at sync time is amazing by comparison to other free software alternatives.
I've also spent considerable time working in the free software world where development is clearly distributed and developers don't generally report to common managers or even necessarily have common goals.
I do have concerns about the multiheaded model. I can see how it can work for small projects. But at some scale, perhaps 128 heads? Or a scale where the heads query never returns the same answer twice in a row? I'm not sure it will actually be manageable. I suspect that at some scale, there will need to be some other form of user partitioning or phased or heirarchical revision propogation in order to track all of the changes and forks. It's not yet clear to me how this will work out or even at what point it will break down.
See last paragraph.rich> Monotone does have some very nice architectural features, rich> though, especially when compared with other current free rich> software offerings. It would actually be nice to hear what you like about monotone (I'm writing notes for a lecture on monotone, so I want to hear things like this. Really, this whole discussion has been a lot of food for thought so far).
Fair enough.rich> So far I haven't heard any serious problems with serials. What rich> problem are you thinking of? The one where I concluded with "This is a huge problem". Of course, that's just my opinion.
|[Prev in Thread]||Current Thread||[Next in Thread]|