Benji York wrote:
Dominik Huber wrote:
We came up with the same solution first. But our problem appears
within the following use case.
A few developers are sharing code on application level (not package
level!) for different dedicated customer projects. They have problems
to setup identical dev-environments (packages with the same revisions
etc.).
I need to carefully reread your message and reply with more detail
later, but I'll make a drive-by comment first. :)
Ultimately, reproducible developer buildouts can never be represented
solely with Subversion (or likely any RCS). If you've been able to
structure your projects such that it works, that's great, but that use
case shouldn't be a driving force behind the common repository layout.
Yes, I know that. I'm fully aware that our suggestion is kind of a
workaround, but it works fairly good in pratice for a wide range of
applications.
Packages are one story of development. Other stories are exemplary
applications that depends on a certain set of packages. Such a set is an
important fine tuning (-> matching revisions or tags etc.) in other
words such a set is know-ledge about package combination that could be
shared between different projects relying on the same exemplary
application. It might minimize the barrier for new contributors and
early adopters - IMO that's fairly important too. That's my driving force :)
Regards,
Dominik
--
Dominik Huber
Perse Engineering GmbH
Jurastrasse 9a
CH-5406 Baden
E-Mail: [EMAIL PROTECTED]
Telefon: ++41 44 586 6886
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
