Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Tim Woodall]

On Sun, 5 Dec 2004, graydon hoare wrote:

> Bruce Stephens wrote:
> > Nathan Myers <address@hidden> writes:
> >
> >>Aliases are good too.  To invent good aliases automatically would be
> >>nice.  Short, sayable and rememberable (if not "memorable") hash
> >>formats, though, are certainly easier to implement.  Once people
> >>stop being spooked by the tutorial, we'll have a better chance of
> >>finding somebody to implement lots of nice features.
> >
> > It doesn't sound like Graydon wants to introduce features simply to
> > avoid frightening potential users.
>
> no, that's not true. I'm quite willing to change monotone to avoid
> frightening off users. software is really all about human factors, at
> some level or another; computers would be happy to sit there idling and
> accepting no input from us.
>
> what I'm unwilling to do is make deep changes without giving a fair bit
> of thought to what we're trying to accomplish. so I'm glad we're
> discussing. I don't enjoy someone throwing down the gauntlet and
> deciding there is One True Way of doing things. there are usually many ways.
>

Here are some of my thoughts for a D-CVS (distributed cvs) that I started
on but didn't have time to get any further than dcvs import.
(Note that I had a few different design goals - my most important was
that it should work exactly the same as CVS unless there was some
technical reason it couldn't. Even when it couldn't always work the same
as CVS it should work the same as CVS until you hit a conflict. In
particular, my design supported everybody working in the same database -
I was using postgresql - which could then be used exactly like CVS if so
desired)

My first problem was that tags/branches etc no longer need to be unique
across all database. Monotone has this problem but ignores it. If two
people create a branch of the same name and then their repositories get
synched either directly or indirectly then you can end up with two heads
that are completely unrelated.

I solved this as follows: every database had a unique ID. Monotone can't
do this AFAICT because you can clone a database with cp. For my design
whether you created the db with dcvs init or cloned an existing db with
dcvs clone your new db would always get a unique ID (baring collisions
reading 16 bytes from /dev/random)

Every tag was then prefixed with this 32 byte hex string when it was
created in the database. However, usually this wasn't visible. You
(almost) always referred to the tag without the prefix. I had also
decided that by default you could not create a tag that was the same as
a tag imported from another DB except for the prefix although this was
going to be configurable/overridable a bit like cvs tag -F.
(Again monotone is like this except that it doesn't allow the override.
If i've imported a xxx.test branch from someone else then I can't create
my own xxx.test branch and ignore the one I've accidently or
deliberately imported)

In addition by default if there was a conflict where one tag was local
to the database and another tag had been imported from somewhere else,
the local tag would be assumed unless explicitly overridden.
Only in the event of there being two identical tags (other than the
prefix) imported would it require you to resolve the ambiguity (and you
would have the ability to favour one of them in the same way as local
tags were favoured)

I couldn't see a clean way of supporting dcvs annotate.
This could work within a single repository but I couldn't see how to
get the same 1.4.5.6 number in two different repositories - if two
people created a branch and then merged either one repository has to
renumber - annoying if you had been spending all your time on the 1.2.3
branch and had got used to it suddenly to disover that it was now 1.2.5
- or the repositories had to disagree so you couldn't refer someone to
version 1.2.3 in their repository - they would have to look in yours.

(the $Log:$ keyword had gone - but then I consider its existance to be
the biggest bug in CVS :-) )

<snip>

>
>    - another local sequential system might involve keeping a sequence
>      number for each author, sorted by date, such that the numbers go
>
>        "derek-10", "graydon-12", "matt-72", "joel-13", "derek-11"
>
>      (this would have an interesting social effect of automatically
>       "ranking" contributors by commit volume, such that I would be
>       committing "graydon-206", just after "njs-38". also the numbers
>       would be quasi-stable and quasi-global for teams which shared
>       complete history.)
>

what would happen if you committed (two different) graydon-206 versions
to two different repositories and then tried synching them?

Tim.

-- 
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

     http://tjw.hn.org/      http://www.locofungus.btinternet.co.uk/