Re: [Monotone-devel] importing

[Tom Tromey]

>> Yeah, I've been assuming that model.  Otherwise don't you need general
>> agreement about branch names across projects?

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

I do like this idea, and I was already thinking that projects could
easily have "hierarchical" branches just by picking names that way.
So e.g. you'd have "/tree-ssa/loop-improvement" for gcc.

I think we'll need documentation on how to manage keys and pick branch
names before a 1.0 release.  Plus, we'll need to change the monotone
database itself to follow the convention, setting a good example.

BTW, if this really is the approach we're taking, then the cvs- and
rcs- import commands will need an extra argument specifying the prefix
to use.

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

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

I share your concern here.  I really don't know what will be clearest
for the user.

cvs operations tend to set a new default, but then cvs doesn't really
let you refer to multiple repositories.  (People have complained a lot
about cvs defaulting to sticky tags during an update, but this problem
can't happen with monotone.)

Tom