[Top][All Lists]

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

Re: cvs commit as root

From: Harry Putnam
Subject: Re: cvs commit as root
Date: Sat, 08 Dec 2001 11:10:32 -0800
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i586-pc-linux-gnu)

address@hidden (Greg A. Woods) writes:

> [ On Saturday, December 8, 2001 at 07:19:10 (-0800), Harry Putnam wrote: ]
>> Subject: Re: cvs commit as root
>> Well, its not really true that it `isn't much different'.  The copying
>> step is really a major pain in the butt.  And represents aboutt 50% of
>> the work needed to keep something in cvs.  Removing that step cuts the
>> work roughly in half and probably considerably more.  Considering it
>> creates extra steps for many other proecess as well.
> If you think those things then you're doing something very wrong.

Let me clear something up here.  First off, I'm not debating the value
of your technique.  Like I said, it is well beyond my level of operation.

Only descibed my home grown technique as strictly amatuer hour.  Just
filled in a little to show how it actualy works.

>> For example: Diffing the file curently in use against the latest cvs
>> controlled version requires a more complex command line.


> For example how would you manage per-user crontab files?  I did it quite
> simply in my makefile with this kind of rule:

In my setup, its not the kind of thing I would be concerned with.
I don't expect to cause mass harm with crontab settings. Although
possible I'm sure.  My crontab usage is rather low level.
I'm more concerned with keeping tabs on things that effect the system
in a basic way.  Things like /etc/fstab /etc/profile /etc/syslog. Or
on freeBSD things like /etc/rc.conf  The heart of the config setup.
rc.firewall and others of similar importance.


> Here's a sample rule for a file that needs another special action done
> to make it really active:

Here we are with proof positive that this is out of my league.  I
can't even tell whats happening in your examples.


> Note that the above rules are really very primitive examples of
> procedures that grew over time and which used only a very minimal set of
> 'make' features.  Modern versions of make would allow much more
> sophisticated rules to be written in a very compact and simple-to-use
> way.

These `very primitive' examples are vastly more complex than anything
I'm doing.

reply via email to

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