[DragonFlyBSD - Bug #2527] Re: git: build: implement automatic world backups

[Chris Turner via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>]

Issue #2527 has been updated by c.turner1.


On 04/12/13 06:28, John Marino via Redmine wrote:

> I don't know what you mean by, there is no mechanism to change auto-backup dir, so we don't have a default.".  That is simply not true IMO.  The operator "?=" means define it as this *if* it's not already defined.  You can predefine auto-backup dir in make.conf.  So those that use NFS could define it anyway they think works.  We don't need to protect for lowest common denominator, it should be defaulted to the most common case.

Agreed that using '?=' provides a mechanism for cfg overrides -
however, in the current patch, auto_backup is '=''ed and not '?='d..
so maybe this is the issue?

To note - my personal typical NFS usage is:

- run a build on machine1
- if the build works, install to another 'second-tier'
   machine (machine2)
- reboot machine2 and 'burn in test' or resolve any upgrade issues
- if machine2 works, then upgrade any other second-tier machines
   and finally machine1

If I'm heavily tracking tip or doing local dev, the 'machine1 build
/ machine2 install' cycle might occur multiple times before installing
to the other machines, however, each individual machine1-machine2
cycle in effect performs a mini-verification of the changes between
builds, so 'fast forwarding' the other machines after a few builds
without having the backup is not very risky.

So really, for most cases, I'd only need the backup on machine2,
since it is the 'build test' machine, and wouldn't need host specific
ones - This is somewhat symmetric with a 'single obj' tree shared
over NFS - e.g.  I don't build N times for N machines, but 1 time
for N machines - similarly, I only need 1 backup for N machines.

But, if this is configurable, defaulting to multiple ${HOSTNAME}
backups is not really an issue since I manage /etc/make.conf on all
nodes, and might be handy for other use cases e.g. where you have
various 'sets' of machines hooked  into a build node upgraded at
different times and want to keep emergency backups during upgrades.

In my scenario, I'd probably only have the auto-backup setup on
'machine2', with the rest configured as 'off'.

Put another way, using the 'NFS centric' hostname directory path
is not necessary in my particular local NFS use case, and if this
setting is configurable, could always be configured by a user
to support multiple backups, thereby making it 'not NFS centric'
by Marinos definition of 'NFS centric' and my NFS use case :D

Anyhow, some thoughts.

Cheers,

- Chris
----------------------------------------
Bug #2527: Re: git: build: implement automatic world backups
http://bugs.dragonflybsd.org/issues/2527

Author: c.turner1
Status: In Progress
Priority: Normal
Assignee: 
Category: 
Target version: 


On 02/17/13 14:43, John Marino wrote:

>      Additionally, every time the "installworld" target is executed, the same
>      directories will be automatically backed up at the location of
>      ${MAKEOBJDIRPREFIX}/world_backup .  These directories could be restored
>      with the new make target "restoreworld-auto".

Bug: This breaks on NFS object trees as the copy tries to set flags,
which can't be done over NFS

Also,

1) getting an 'off button' back for this would be swell
2) build(7) should probably be updated with whatever the final result is.

personally, I'd prefer this was optional behavior with an 'on' switch,
(e.g. it seems sort of like a 'developer setting' like CFLAGS, etc)

but, that's me.

sorry to back seat drive with no attched patch - lifes a bit hectic ATM.

Cheers,

- Chris


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account