Re: [Monotone-devel] importing

[graydon hoare]

Tom Tromey <address@hidden> writes:

> graydon> possibly, though that assumes a sort of 1 project <-> 1 database
> graydon> relationship, otherwise which head would you mean?
> 
> Yeah, I've been assuming that model.  Otherwise don't you need general
> agreement about branch names across projects?

true enough. another possibility is to suggest branches get qualified
by DNS names, the way I'm implying key IDs ought to be qualified like
email addresses. so I could call the branch address@hidden (or do
like java / usenet and call it net.venge.monotone.head) or something,
rather than just 'monotone'.

advantages of the latter scheme (net.venge.monotone.head) are:

  - it's obviously *not* a real host name, but it's related to DNS
    so people have a courteous conflict resolution system built in.

  - it permits lots of reasonably descriptive branch names with a 
    natural concept of "sub-branches" (though they would be fictitious)

  - I can imagine .. though not very concretely .. some heuristics for
    merge resolution or automatic propagation making use of this
    fiction of super- and sub- branches.

in any case the names will really only "clash" if two people whose
certs *you're* listening to choose the same name, so some simple and
courteous convention will be sufficient. it doesn't need to defend
against attack. the crypto does that.

> What my unfinished patch does is add a new file that stores key/value
> pairs.  Currently only "branch" and "database" have any meaning.
> These are automatically read at startup from MT/options, then (this
> bit isn't written) stored again, if needed, at exit.

hm, maybe. the thing I'm concerned about is a situation where a
command line option (say --branch) sets a persistent value as a *side
effect*; because then you have to remember to "set the option back" to
its original value, which you might have lost or forgotten. it might
be the right thing to do, but I'm not certain. what do you think?

-graydon