--nextPart1916545.ApqtP5mRGl
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday, 10. February 2005 07:06, Chris Pressey wrote:
> > I think the goal ought to be a layout that does not require
> > merging to update a system. Mergemaster may be fine for a UNIX
> > expert, but it's hell for a general user.
i have to agree there, it should be as easy and streamlined as it can get.=
=20
BUT: somebody changing stuff in /etc/services can't be considered as a=20
general user. If I change my rc.d scripts, I am likely an UNIX expert=20
(well, at least i know how to adjust my rc.d scripts).
so maybe we should try to support two areas:
1. common changes by general users. that's not much, rc.conf,=20
passwd/groups, resolv.conf, hosts, ssh/*_config
these should be updated as easy as possible. but well, defaults work well=20
with rc.conf, but then it gets harder.
I still think a three way merge would be the best, but for the general=20
user not using a unified diff, but plain english text. example (made up):
You have changed the file `/etc/ssh/sshd_config' before. An update to this
file is available. I can help you updating your copy.
The following section is an excerpt of the original file:
=2E..
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=3Dno
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
=2E..
You changed it to read:
=2E..
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=3Dno
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
=2E..
Unfortunately, I can't transfer your change to the new version. Please=20
help me with that; the new pristine version reads:
=2E..
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=3Dno
#UsePAMAuthentication no
#AllowTcpForwarding yes
#GatewayPorts no
=2E..
Please change the text to suit your needs.
Ah well, a little bit long. But most changes can actually be applied=20
without collisions. Which means the user just gets presented (if he opted=20
in/not out) his changed version and the new merged version. most time=20
they will just say "yes, okay, that looks good. where was the change=20
anyways"
> What do people think about using CVS for this?
I'd rather use RCS, the remote and can-checkout multiple times features=20
are not needed here.
> - Standard tool with general applicability, in the base system.
> - Designed for handling merges and any conflicts that arise.
> - The admin can specify which files not to touch, using .cvsignore.
> - The admin can make unobtrusive comments on their changes, in the log.
> - The admin can roll back their configuration to any previous point.
all that is possible with RCS, too
> - The admin can keep the master configuration repo on another machine.
well, you need CVS for that. after all, both could be used interchangably.
> - Heavyweight solution; it's overkill.
only if you perceive it as CVS as a general user. if you don't notice=20
anything about it, it's okay.
> - It's yet another component to administrate; more hassle.
if done properly, only for (us) programmers.
> - Its method of handling conflicts is less than optimal.
true. does cvs even do a three way merge? needed to be done better then.
> - The admin can't use its features from single-user mode.
true, but these are additional features, so there is no loss in comparison=
=20
to now. or an /sbin/etctool gets linked statically.
cheers
simon
=2D-=20
/"\
\ /
\ ASCII Ribbon Campaign
/ \ Against HTML Mail and News
--nextPart1916545.ApqtP5mRGl
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQBCCzzhr5S+dk6z85oRArTIAKDhfTIGSQ3lagO1Uhe8OmrxFRROnQCdHhBe
UXu1sR62R4Bg+Yxf/7r+Lcg=
=aXke
-----END PGP SIGNATURE-----
--nextPart1916545.ApqtP5mRGl--