[Zope] Version Control in Zope / Managing releases
Casey Duncan
casey.duncan@state.co.us
Fri, 22 Sep 2000 14:01:24 -0600
<snip>
1) "Code Collisions." - Developers overwriting each other's work.
2) Partial updates - Right now, we have new pages for marketing
content that are held up because we don't have our new features for
the application done yet. So we can't update marketing pages without
updating the app at the same time, (one ZODB) unless we directly
update the production servers. (Eeek!)
<snip>
Forgive me if this is overly simplistic, but these problems can both be
addressed or at least worked around by using versions, no?
Each developer should have his/her own version object. To lock the object
(and solve #1), a developer just needs to open it and click change. Then to
unlock whatever was worked on and commit it, save the changes to the
version. Granted this means only one person can work on an object at one
time. This can be worked around by proper modularization of your app. Also,
developers need to remember to save their version changes so that others can
work on those objects too. This also has a side benefit of letting you
document your changes in a more meaningful way. Also, an entire set of
changes can be rolled back if it breaks something.
#2 is more about what versions were designed for. Just work on the app code
in a version and don't commit it until it's ready. Granted this assumes that
you have sufficiently separated the data, layout and code and aren't using a
lot of external methods. If this isn't a possible solution, I would just
create a production version of the feature in one folder that might not be
complete but can be updated, and work on a second copy in another folder
that isn't accessible to everyone yet.
If this won't work please elaborate on your design and maybe someone will
have better idea.
Good Luck!
-Casey Duncan