On Fri, 30 Sep 2005, Yar Tikhiy wrote:
Obviously, in order to do a 3-way merge, we need information about
the old versions of original files as well. However, currently we
have only the new versions in /usr/src and local versions in /etc
for mergemaster to work with. I'll be glad to hear how et
> : cd
> : make etc-diff # ensure your workspace reflects what is in /etc
> :
> :
> : make import # import the latest /usr/src/etc into etc workspace
> : make diff # look over the changes
> :
> : make install# install to /etc; do mkdb etc.
> :
> :
> : Finally:
> : make commit
In <[EMAIL PROTECTED]>, Bakul Shah <[EMAIL PROTECTED]> typed:
> Here is an idea for the mergemaster hackers' consideration!
>
> By keeping /etc files in a source repository one can archive
> and document all local changes. This is useful for some of
> the same reasons for which we keep sources in
In message: <[EMAIL PROTECTED]>
Bakul Shah <[EMAIL PROTECTED]> writes:
: Here is an idea for the mergemaster hackers' consideration!
:
: By keeping /etc files in a source repository one can archive
: and document all local changes. This is useful for some of
: the same reasons for whi
Here is an idea for the mergemaster hackers' consideration!
By keeping /etc files in a source repository one can archive
and document all local changes. This is useful for some of
the same reasons for which we keep sources in a repo:
recovery from mistakes, reuse of old code, checking who did
wha
Kevin Oberman wrote:
>>Date: Thu, 29 Sep 2005 23:41:57 -0700
>>From: Doug Barton <[EMAIL PROTECTED]>
>>Sender: [EMAIL PROTECTED]
>>
>>One of the design decisions that you need to be aware of for this project
>>since day one was to try and balance intelligent behavior and configuration
>>options tha
On Fri, Sep 30, 2005 at 02:37:05PM -0700, Kevin Oberman wrote:
>
> You just hit on one of my pet peeves with mergemaster! Contrary to what
> you say: "every single default for mergemaster is to do nothing", when a
> file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default
> is to d
> Date: Thu, 29 Sep 2005 23:41:57 -0700
> From: Doug Barton <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> One of the design decisions that you need to be aware of for this project
> since day one was to try and balance intelligent behavior and configuration
> options that would be useful for
On Fri, Sep 30, 2005 at 09:07:16AM -0400, John Baldwin wrote:
> On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote:
> > [Replying to everyone who mentioned etcmerge or 3-way merge in general]
> >
> > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote:
> > > It is worth while to mention sy
On Friday 30 September 2005 23:50, Ashley Moran wrote:
> Unfortunately it seems that config files for the subsystems (eg SSH) are
> stored separately in the CVS tree and I didn't have time to work out
> where they live.
The trick is to get the system to build you an /etc - see how mergemaster does
Daniel O'Connor wrote:
On Friday 30 September 2005 18:23, Ashley Moran wrote:
It sure would be nice :)
One thing would be to have automatically fetched etc directories so when you
ran it for the first time it would grab a release version of etc for you :)
Hmm.. I'll try and add that if I get s
On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote:
> [Replying to everyone who mentioned etcmerge or 3-way merge in general]
>
> On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote:
> > It is worth while to mention sysutils/etcmerge.
> >
> > Having the "three-way" merge makes the process
On Friday 30 September 2005 18:23, Ashley Moran wrote:
> > It does have problems handling DB files, but that is usually not a big
> > problem to fix.
>
> I read about etcmerge in BSD Hacks and there's been no going back for
> me. It seems pretty stable even though it's not been updated for a good
On Friday 30 September 2005 18:12, Brian Candler wrote:
> On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote:
> > The fruitiest features are as follows:
>
> Will it automatically install new versions of files where the old one was
> not altered? That's my biggest bugbear with mergemaster -
Brian Candler wrote:
That's my biggest bugbear with mergemaster - it asks you about
a zillion files in /etc/rc.d which you have to manually agree to overwrite
just because the RCS ID has changed. In those cases where you've not altered
them yourself, I think you should just get the latest versio
On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote:
> The fruitiest features are as follows:
Will it automatically install new versions of files where the old one was
not altered? That's my biggest bugbear with mergemaster - it asks you about
a zillion files in /etc/rc.d which you have to
[Replying to everyone who mentioned etcmerge or 3-way merge in general]
On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote:
> It is worth while to mention sysutils/etcmerge.
>
> Having the "three-way" merge makes the process much better. The primary
> way I've shot myself with mergemaster
On Thu, Sep 29, 2005 at 11:41:57PM -0700, Doug Barton wrote:
>
> First let me say that you've obviously put a lot of work into this, and you
> have some very interesting ideas here that are worthy of further discussion.
> Please don't let any of my comments here be understood as criticism, or an
>
Daniel O'Connor wrote:
This work does look neat, but..
Try etcmerge :)
It's a bit of a pain to get started with it, but it is a *lot* faster (human
input wise) than mergemaster. It only asks you about files that you have
modified rather than ones that have been changed by committers (ie does a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yar,
First let me say that you've obviously put a lot of work into this, and you
have some very interesting ideas here that are worthy of further discussion.
Please don't let any of my comments here be understood as criticism, or an
attempt to discou
On Friday 30 September 2005 08:15, Yar Tikhiy wrote:
> Feedback is welcome. And please please don't skip making a backup of
> your /etc before running mergemaster! I can't be responsible for its
> loss due to bugs in my code or whatever.
This work does look neat, but..
Try etcmerge :)
It's a bit
Folks,
I've got tired of dumb default choices mergemaster(8) offers
and modified it to be a bit smarter. Upgrading /etc often,
as when following CURRENT, is much less pain to me now. The
modified mergemaster is available from P4 for now since
I'd like to have it tested well before it hits the sr
22 matches
Mail list logo
