On Tue, Sep 1, 2009 at 9:45 AM, Jeffrey J. Kosowsky
<backu...@kosowsky.org>wrote:
> Hopefully we can put this part of the thread to rest.
> I will try to summarize my conclusions based on the vociferous
> feedback I have heard and then throw out some compromise roadmap
> suggestions that may be workable and helpful:
>
> - While a hybrid database/filesystem approach would certainly bring a
> number of advantages in some areas, it also would require a lot of
> work and would introduce a host of potential
> stability/robustness/speed issues. Most such issues are probably
> solvable but few would be willing to risk switching to a new
> approach until it was proved stable and there is likely to be little
> if any interest in investing in such an effort in advance of such
> proof. Other people are not interested in a new approach simply
> because the current approach satisfies all or most of their needs
>
> Recommendation: Keep as-is
>
>
I have to disagree and will be respectfully vocal because you can see that
this is a top 10 topic in this list. Also, I dont think that open source is
meant to stagnate. I dont believe the future of backuppc is simply
improvements to the cgi or some bugfixes and minor adjustments.
> - While there are block-level approaches to copying/moving the
> BackupPC tree, a continuing stream of users still would be
> interested in a file-level approach. Additionally, the ability to do
> "incremental" backups would be welcome. Holger, myself, and perhaps
> others have at times in the past suggested various O(n log n)
> algorithms for copying the tree & hard links using the known
> structure of the pool and pc trees. Myself and others have also
> suggested potential ways of doing incrementals either by tracking
> changes or by identifying changes on the fly (with the key 'gotcha'
> changes being the chain renumbering). None of these approaches
> appears to be particularly difficult though it does require a
> commitment of time
>
>
See the next paragraph on how/if I think this should be explored. This isnt
a terribly important process, but an important outcome. certainly
developing some good methods to work would be very helpful but I dont know
that I think that backuppc should concern itself with mirroring the data in
this manner. Just like backuppc is disk agnostic, the operating systems
tools should handle the hardware and expose a useful layer to backuppc. sure
there is talk of underlying hardware but that isnt the focus.
#1 rule of project management is to define your goals before implementing.
I have not yet seen Craig express his views on this but until the roadmap is
written in permanent marker there should be more discussion. more bluntly,
should a lot of work be done on tweeking the current system without a
roadmap stating the goals? In the spirit of open source, this should be
decided on and then choices can be made to contribute, not to contribute, or
to fork/start a new project.
In reading back my posts it does seem that I am making an effort to passive
aggressive bash on the current system, which is not the case. I just know
that mature projects do well by taking years of experience and a strong
community and replacing aging concepts and code while re-using or recycling
good code and concepts.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
