DragonFly BSD
DragonFly bugs List (threaded) for 2013-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: John Marino via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 8 Apr 2013 09:52:13 -0700

Issue #2527 has been updated by marino.

The original incarnation of this is similar to your patch, but dillon asked for it to be reworked and simplified.  Now it's blown up in complexity again.

On the "makefile" patch, IIRC, you're only supposed to document targets that you can actually run.  You can't "make backupworld-auto-clean" for instance, so it's would only appear on Makefile.inc

On quick glance, it seems that by removing the timestamp to solve one problem, you reintroduced another problem: The auto-backup (if enabled) will occur every time you "make installworld".  In the case where you buildworld once and "make installworld" many times, this is undesired.

The use of a tarball is probably an improvement especially if it allows backup of make, cp, etc, and I suspect it's a key in dealing with the chflags/nfs issue.

I would disagree (also based on Dillon's direction) that the AUTO_BACKUP is off by default.  
I'm also not sure about the redefinition of the AUTO_BACKUP default.  That seems to favor an NFS implementation.  Wouldn't the standard case be a single machine with local backups?  In that case, the default is a bit obnoxious.  Not something to fall on a sword for..

I think it's a big step in the right direction.

Bug #2527: Re: git: build: implement automatic world backups

Author: c.turner1
Status: In Progress
Priority: Normal
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


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.


- 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

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