Waynn Lue wrote:
> Yeah, that's why I was hoping to maintain a separate install, since it
> would be easier to diff the patches.
>
> Shawn: Thanks for the suggestion to extend, I only wanted to make
> small changes to an existing function though, so it's harder to do it
> that way. My other thought was to refactor the underlying code base to
> make it easier.
>
> Waynn
>
> On 7/5/09, Greg Beaver <
greg@...> wrote:
>> Waynn Lue wrote:
>>> I wanted to makes some local edits to a PEAR package that I downloaded in
>>> order to build some custom functionality into it. What's the best way to
>>> manage this process to ensure that I don't accidentally blow away any
>>> changes if I update the package? Should I just copy the entire package to
>>> my own source repository, then use that directly instead of the PEAR
>>> package? And if I do it that way, is there an easy path to upgrade it?
>> Best would be to follow Shawn's suggestion. If you do need to make
>> changes, you should contribute them back to the package, PEAR is an open
>> public repository, it may be incorporated and help others in your
>> situation as well (this is the point of PEAR and of open source).
>>
>> Greg
>>
Well, it depends upon the nature of your changes.
You can copy the parent class's code and modify it in your class, or you
can call parent::somefunc(); in your class and then run your custom
code. It just depends upon what you are changing and how.
I for one would never have anything in production (or was considered
completed) where I had to diff files or look through code before I
updated a package or framework. Actually, for me anyway, I wouldn't
update/upgrade any shared library/component on a site/app unless I was
still developing the code and it provided some extra functionality that
I needed, or it patched a security vulnerability or maybe fixed a bad
bug that I was struggling with.
--
Thanks!
-Shawn
http://www.spidean.com--
PHP General Mailing List (
http://www.php.net/)
To unsubscribe, visit:
http://www.php.net/unsub.php