On Fri, Nov 23, 2012 at 06:32:15PM +0100, Thomas Vander Stichele wrote: > Heh :) > > well, my goal was more to provide you guys with the tools to get the > github repo set up as you want it, before patches come in. > > I don't know who currently maintains dirvish, or who should be hosting > the actual repo, but it shouldn't be me. > > Any takers ? Any comments ? Anything you want to change in the repo > conversion ?
Hello there, I host the dirvish.org website, which has a subversion server. Dirvish is pretty much how jwshultz left it, with a few excellent community patches rom a few years ago. Not many patches are coming in these days, and sadly, most are intended to change (aka break for others) the behavior, not fix defects. Whither dirvish? Well, some folks want to add secret sauce and sell it as proprietary - sorry, jwshultz provided divish via the open source license, it's not BSD so you can't extend it that way. It would not be difficult to completely replace with new code. rsync remains GPL, and the foibles of Windoze and Mac can limit the usefulness of rsync-based software on those platforms. Some folks want to change the functionality, but without testing the impact on large existing operations. For example, dirvish is used for backups (with major mods) by the Open Source Labs at Oregon State University, which hosts the linux kernel, mozilla/firefox, and drupal, along with many other important open source projects. I think it would be great if dirvish became even more useful to them, and their patches were available to us, but we must not make their backup or restore process fail. Sometimes, folks want to make big changes like transforming dirvish into a "push" backup system. That particular change might be more convenient for some, but mostly convenient for system crackers looking for an easy way to hack into the backup server and then subsequently all the machines for which it contains security information in the backups. Sorry, but pull backups make far more sense security-wise, though we can develop handshake methods that make the initiation, interruption, and continuation of backups more intelligently scheduled. All that said, if anyone wants to create new versions of dirvish and support them on github or other server, I would be glad to link to them. I will even provide space on the main website to describe intended use. I will insist that both the advantages and drawbacks are included in the descriptions, including pointers to longer descriptions (perhaps on the wiki) of how the changes were tested. I would especially like to see improvements in installation, testing, validation of existing backups, and most especially restores. Restores are the weakest link - while automated backups are dandy, system restores are the main reason to make backups in the first place, and system restores are never easy, usually needed during unscheduled disasters. I wrote my own adhoc scripts for this, and can generally restore one or two machines in an afternoon, but my hacks are not generalizable; and I don't do fire-drill testing of them nearly often enough. There is indeed much room for improvement, and a git repository would be a good way to get that started. But please keep in mind the installed base, and the consequences of "improvements". FYI, I migrated the wiki to Moin, and can give access to others. The wiki has been abused in the past, so I am judicious but not miserly in my trust. Keith -- Keith Lofstrom [email protected] Voice (503)-520-1993 _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
