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

Reply via email to