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

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Tue, 19 Apr 2005 08:08:47 -0700, "K. Richard 
Pixley" <address@hidden> said:

rich> This is why I suggested that the repository be named.
rich> Presumably, the name would be based on domain name, but the real
rich> point is that domain names follow hierarchical delegation.

hierarchy isn't really important here.  The networking model of
monotone is really quite p2p, even though human nature tends to have
us go for the single and same source.

rich> > 2. I could be operating two (or more) separate monotone DBs on
rich> >    the same machine.  OK, we could make some special effort to
rich> >    try and get the two copies to know about each other's
rich> >    numbers.
rich> 
rich> I wouldn't bother.  I'd just name them with subdomains.
rich> 
rich> Personally, I'm going to mock all my repositories to look like
rich> the company's domain.  So project1.noir.com, project2.noir.com,
rich> etc.  They don't really correspond to domain names with unique
rich> IP addresses, but to cnames.

I've done something similar, depending on the customer and so on.

rich> > 3. I have machine foo.bar.com - what to do about some
rich> >    unpleasant person who decides to incorrectly name their
rich> >    machine foo.bar.com too?  (There are a number of
rich> >    workarounds for this, each with advantages and
rich> >    disadvantages)
rich> 
rich> You do nothing.  It's up to the administrator of bar.com to
rich> resolve this collision.

The point is, what happens in the mean time?  Suppose this unpleasant
person has netsynced my database, then made some commits to his
database while I do some commits to mine?  When he then "takes over",
he will have pushed along revisions that look like they came from me
but didn't, and worse, that conflict with revisions I've committed to
my database because they happen to have the exact same numbers.

This is a huge problem, and nothing the administrator of bar.com can
do anything about.

rich> Now, if you decided to change the name of an existing
rich> repository, /that/ might represent a potential problem.  The new
rich> name would work, but anyone who ever tried to reuse the old name
rich> would create a collision.  I'm not sure this is a problem in
rich> practice, though.

It's a potential problem at least.

rich> > 4. The number's not actually monotonically increasing when
rich> >    viewing the tree as a whole.  Ignoring branches, I'd still
rich> >    get
rich> >
rich> > 1:foo.bar.com
rich> >       |
rich> > 1:baz.foo.com
rich> >       |
rich> > 2:baz.foo.com [...]
rich> >
rich> > ...which kind-of seems to defeat the point.
rich> 
rich> The point is two-fold:
rich> 
rich> 1) provide human readable visual ordering.  Since global
rich>    ordering really isn't possible, the only ordering that has
rich>    any meaning is per-repository ordering.  And that's what
rich>    you're seeing.

You have seen what history can look like with the multi-head model
monotone uses, have you?  Taken from one of the tests:

  #              A
  #            / | \
  #           F  C  G
  #           |/ |  |
  #           D  E  |
  #              \ /
  #               B
  
  # B and D are heads of branch.main and branch.fork respectively, we want to
  # "propagate branch.main branch.fork". 
  
  # The revs F, C, and D are members of branch.fork. 
  # A, C, E, G, and B are members of branch.main (C is shared)

And this is actually a very simple graph, compared to what can be seen
in the history of monotone itself.  Now, let's say that the above
graph was done in the following order:

  A, F, C, D, E, G, B

The graph would then be (with :foo.com removed from all revision
numbers):

  #              1
  #            / | \
  #           2  3  6
  #           |/ |  |
  #           4  5  |
  #              \ /
  #               7

Ordering?

Now, if you want something nice and visual, you need to have a look at
monotone-viz.  THAT's a nice tool to visualise the order of things.
Works a lot better than any sequence of numbers.

rich> 2) providing unique id's.
rich> 
rich> I think serials on named repositories do address these points.

And so do SHA-1s.

There were a few problems (at least one being very serious) with
serials.  Those problems just aren't with SHA-1s.  I let that speak
for itself.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis