monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] New branch name with no other changes


From: Jerome Baum
Subject: Re: [Monotone-devel] New branch name with no other changes
Date: Thu, 16 Jun 2011 20:33:50 +0200

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

_MTN/monotonerc is already checked per
<http://www.monotone.ca/docs/Lua-Reference.html#rcfiles>.

> Or be a checked-out file that an option in _MTN/options indicates is to
> be read...

This would allow for versioning. But we have to be careful to avoid
malicious situations. So just stick with _MTN/monotonerc, and let the
user load a versioned file if they really want to shoot themselves in
the foot.

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

I think we shouldn't separately consider system and distro monotonerc.
It's really up to the distro to make that separation. If you think
Debian isn't well-organized, that's a Debian problem, not a monotone
problem. So, solve it by changing Debian, not monotone.

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

Not a monotone problem, but if you want better versioning for your
distro, have you looked at cfengine and family?

-- 
Jerome Baum
tel +49-1578-8434336
email address@hidden
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA



reply via email to

[Prev in Thread] Current Thread [Next in Thread]