Re: New branch name with no other changes

On Thu, Jun 16, 2011 at 06:20:53PM +0200, Richard Levitte wrote:
> In message <[email protected]> on Thu, 16 Jun 2011 08:40:52 -0400, Hendrik Boom <[email protected]> said:
> 
> hendrik> On Thu, Jun 16, 2011 at 09:38:36AM +0100, CooSoft Support wrote:
> hendrik> > Nuno Lucas wrote:
> [...]
> hendrik> > 1) Yes the documentation, which I think is very good btw, needs to make  
> hendrik> > the alternate `mtn cert... mtn update' approach to branching much more  
> hendrik> > obvious than it is now and why you might want to do it that way as  
> hendrik> > against the mtn ci -b way.
> hendrik> 
> hendrik> Yes, the documentation is probably an adequate place to solve this 
> hendrik> problem.  Possibly a note in the section on mtn approve, giving the 
> hendrik> two-step process.
> 
> Hmmm, people also need a way to find it...  maybe a section like
> "Tricks and tips"...
> 
> hendrik> > 2) Implement a global rc file mechanism, I read the comment about  
> hendrik> > wrapping it in a script, yup that is a possibility (certainly for now).  
> hendrik> > but most tools have the concept of global and user rc files. If this was  
> hendrik> > done then interface extensions could more easily/practically be rolled  
> hendrik> > out via the extras package.
> hendrik> 
> hendrik> Careful with this.  You can reasonably want such scripting by the user, 
> hendrik> ny the project and system managers, by the Linux distribution, and by 
> hendrik> the monotone developers themselves.
> 
> User: covered (~/.monotone/monotonerc)
> 
> Project manager: uhmmm, ideas?

That could be up to the project manager, and he could require his users 
to include it.  But that wouldn't work, because one user could very well 
work on multiple projects.  Perhaps is could hide in the _MTN directory.
Or be a checked-out file that an option in _MTN/options indicates is to 
be read... 

> 
> System manager: would need something like /etc/monotonerc
> 
> Linux distribution: they aren't really different from system managers,
> and could easily create a /etc/monotonerc that includes a
> /etc/monotonerc.local, which can then be changed by the actual system
> manager.  Linux distributions (oh, and I'm sure other Unix flavors do
> this as well) do this all the time (Debian is cluttered with such
> hacks, in a nice way).

What makes Debian cluttered is that there isn't a systematic mechanism 
to organise all these hacks.

So we;d look for:

a project monotonerc
a user monotonerc
a system monotonerc
a distro monotonerc

All of these would be in standard locations (such as ~/.monotone/monotonerc)
and we'd take whichever one we find first.  We look at the further out 
ones only if the more local one allows it (or fails to prohinit it).


And I really would like /etc to be under revision control, with a venrod 
branch for the distro to put changes in.  But that would require a deep 
change in the OS installation procedure.  And the distro would probably 
pich the wrong revisioning system.  Almost everyone does.

-- hendrik
k