config file under RCS
Sebastien Estienne
sebastien.estienne at gmail.com
Tue Dec 20 11:00:05 UTC 2005
2005/12/20, Fabio Massimo Di Nitto <fabbione at ubuntu.com>:
> Sebastien Estienne wrote:
>
> >>>
> >>>Right, but without the crontab you notice it immediately, and not one
> >>>hour later when you may be away from your keyboard
> >>
> >>i don't see how. mind to explain?
> >
> >
> > As i explain in my first mail the fact is that samba reload the config
> > file immediately when it noticed a modification. (i use samba as an
> > example, other apps may do this)
>
> this still happens with or without RCS. it is a totally indipendent behaviour.
>
> > So without RCS/crontab as soon as i make a mistake i know about it.
>
> Even with it. I think what you don't understand is that /etc is not pulled from
> an RCS. It is an RCS it self that gets pushed somewhere.
>
> If you revert your logic (and that's how it will works) you will see that
> the problem you are trying to raise was/is/will not be there.
>
> > With the crontab, the commit may happen while i'm not log in anymore
> >
> > I can explain why i don't like this kind of automatic , timing based things:
> > 1) i think we should more or less force the admins to write a log
> > message (svn -m "i added a new vhost") for each commit they do, it
> > gives valuable information, if the commit is automatic, what will be
> > the message?
>
> the autocommit will carry a timestamp of when that happen (if there is a need to
> commit of course).
>
> > 2) we don't really need an auto commit, if he didn't commit, that is
> > up to him. Maybe he prefers to finish tomorow.
>
> perhaps he forgot to do it?
>
> > 3) this mean that you can't work more than 1 hour on a config file
> > without being forced to commit? (i hope it's not every plain hour that
> > it auto commit)
>
> and if it is all configurable?
>
> Ideally all of the above is configurable. We won't even force /etc on RCS.
> Assuming we will get to implement it, admins will be able to choose and configure.
>
> >
> > I see why you want this autocommit thing: so a change is never lost in
> > the "local" repository.
> > But if he modify a file, this means that he want a result. I don't see
> > any reason he would log out without commiting and checking that the
> > change he made , worked. The crontab trick may just make it work
> > "magically", and he may not understand why.
>
> You assume that all admins can work that way, and the reason why we did propose
> the autocommit is exatly because reality proves the other way around.
>
> >
> >
> >>>You didn't comment on the "PS1" and "logout" ideas, i think they are
> >>>still valid with the crontab autocommit, it gives an immediate visual
> >>>information.
> >>
> >>while the idea might be valid, it would require changes to all shells to check
> >>for that specific plugin and status. it is a fragile point to touch that i am
> >>not keep to modify.
> >>
> >
> >
> > I'm willing to implement this, i don't really see the need to
> > implement it for all shells other than bash/tcsh/zsh.
> >
>
> Nope.. that won't work. You can't assume what shell the admin is going to use.
> either all or none.
>
I just assumed that bash/tcsh/zsh covered 99% of the admins shell on a
linux system (i even assumed that bash was 90%) and that the reamin
1-10% were clever enought to make it work with their shell of choice.
I may be completely wrong, but i still think it's better to have it
for bash only than not having it at all. And nothing can stop someone
using Ash or any other shell to contribute to the project if he feels
the need...
> Fabio
>
> --
> I'm going to make him an offer he can't refuse.
>
> --
> ubuntu-server mailing list
> ubuntu-server at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-server
>
--
Sebastien Estienne
More information about the ubuntu-server
mailing list