Managed packages are a massive hassle. Having been through dozens and dozens of implementations, and several managed package implementations, I only recommend using managed packages when you need to deploy to somewhere and guarantee the installing org will not have access to source code. This mostly applies for AppExchange apps. If you don't have this requirement, managed packages are much much much more hassle than they are worth.
The toolset for packages is really the bare minimum needed for AppExchange developers. Release packages impose very strong restrictions on future changes (e.g. can't rename or remove lots of things), but beta packages can only be installed in sandbox/test orgs, AND they require an uninstall first. This is the main reason that MP's are annoying, but there are many others: namespacing is under-implemented, code sharing between packages is annoying, salesforce imposes an odd limit of N (I think 10) namespaces being called per context, the management of package components is much more difficult than non-package, you can only create one managed package per developer org, etc. Basically not designed for the use case you mentioned and should be avoided at all costs if you don't need to hide your source code and/or install via AppExchange or TrialForce.
I manage all custom codebases by unmanaged packages with package.xml files, deployed between environments using the (Ant) Force.com Migration Tool with a set of convenience batch files for backing up, timestamping, version control, etc. It's a much easier way to go. Changesets would be a close second. I don't recommend managing deployment with Eclipse because IME it's not 100% reliable and is prone to mistakes when you have multiple people updating the source org simultaneously.