monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] newbie question - SHA1 vs serials


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:
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 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.

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?
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.
  
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.

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.
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).
  
See last paragraph.
  • automatic forks in the repository
  • the potential for revision propogation in the background, unattended
  • the ability to separate syncing from merging
  • a decentralized user based authentication mechanism, (this is a dual edged sword, though, it doesn't scale and it doesn't lend itself to centralized control).
  • generalized database for associating metadata with revisions
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.
  
Fair enough.

--rich

reply via email to

[Prev in Thread] Current Thread [Next in Thread]