[Kapil Thangavelu]
[snip debating over what the book says]
> sigh.. debating over what the book says isn't very productive.
That's for sure <wink>.
> my conclusions at the end of my previous email, namely that what this
> layout will accomplish for the zopeorg repository in terms of avoiding
> renames of checkouts will likely be fairly limited in pratice, still
> win me out against deviating from the standard layouts.
I think your points about stitching stuff together are crucial, since a lot
of that indeed occurs in the Zope world. You have svn experience too, while
I don't, so I'm happy to yield to that.
The other crucial thing is that we document clearly what we're doing. I
said before that newcomers to svn won't understand the alternative
structures, and I still believe that. By sheer coincidence, someone on
comp.lang.python today posted this:
"""
I'm experimenting with svn. What is the best way to set up the
original project, anticipating "importing" to a truck-and-branch
world?
When I start I have:
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test
To do branches, I think I'm supposed to get to end up with:
myproject/
trunk/
doc/
mypackage/
stable.py
test/
go_test
branches/
branch1/
mypackage/
changing.py
test/
go_test
...
"""
If that demonstrates a lack of understanding of how svn truly works, what
that really demonstrates is that *of course* newcomers to svn don't
understand how it truly works, and I think it's hard to come away from a
first pass over the svn book without believing this specific directory
structure is more magical than it really is.
monkey-see-monkey-do-is-a-tough-default-to-overcome-ly y'rs - tim
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
