[OPEN-ILS-DEV] [OPEN-ILS-DOCUMENTATION] Documentation question: restoring customizations after upgrade

[Dan Wells]

Hello Dan,

Just thought I'd add that I have borrowed a few things from your OPAC skin in ILS-Contrib, so thanks for making it available.  It's been really nice having somebody at least one step ahead of us so far.

Dan

>>> On 1/20/2010 at  2:52 PM, Dan Scott <dan at coffeecode.net> wrote:
> On Wed, 2010-01-20 at 13:51 -0500, Joe Atzberger wrote:
>> Dan, 
>> 
>> 
>> This sounds like a good case for a DVCS, allowing you to have your
>> changes more in-stream than in-parallel.  Now that they are
>> available, have you considered using a either the launchpad or github
>> repos as a starting point?  
> 
> Not really. It's been working well enough for us, for the limited number
> of times we've gone through the complete process (twice, I think), so
> it's hard to justify throwing effort into a different direction. We went
> with ILS-Contrib from the beginning in the hopes that our work might be
> reusable by others who had the same needs that we do, and at the time
> that was the only publicized repository (and effectively it still is the
> only publicized repo).
> 
> Even if we did move to a DVCS, though, I'm not sure it would change how
> we handle rolling out our skins. We certainly wouldn't want to duplicate
> all of the files for each skin in the DVCS.
> 
>> Upsides: lighter weight, less maintenance having to duplicate updates
>> in parallel, your changes would live upstream from the your production
>> install, and you could easily switch back and forth w/ stock code.  
>> 
> 
> I dunno about lighter weight or less maintenance. It's not like we're
> updating our production site (or even our test server) every day, and
> we're only talking about a handful of files.
> 
>> Downsides: conversion, possible mirror latency, new tools.  
> 
> Well, I'm familiar with bzr, so no downside if we went that route, and
> the six-hour or so latency of Launchpad doesn't bother me given how
> rarely we do a complete update of our production or test sites.
> 
>> I suppose if you aren't doing it though, than probably nobody is yet.
>>  But as far as documentation goes, it might be better for us to
>> outline the process of maintaining customizations w/ DVCS so as to
>> have everything under one paradigm that's a little more portable,
>> durable and likely to succeed. 
> 
> I definitely agree that this would be valuable, and if somebody (else)
> makes it an easy path to follow then I'll be second in line :)