> > > This diff brings up a good point for us to discuss. What is the preferred > method to check something out from SVN? Most anything we do requires at > least two SVN checkouts. > > A classic example for English: > > - cd /where/doc/stuff/is/stored > - svn co http://svn.php.net/repository/phpdoc/en/trunk phpdoc/en > - svn co http://svn.php.net/repository/phpdoc/doc-base/trunkphpdoc/doc-base > > Leaving us with en and doc-base directories. And then for phpdoc-all it > gets trickier, well, a lot longer. The choices seem to be either: > > - use svn:externals > - create and promote scripts for this > - change our structure/layout > - ... ? > > I don't understand the pros and cons of using svn:externals but the topic > seems to have a holy war type feel to it. Is this true and/or avoidable? > What are the pros and cons? If a script is used, I imagine it'd be stored in > doc-base then used to checkout languages. I also imagine other places at > php.net would use it (or svn:externals). >
using svn:externals have some restrictions ( http://svnbook.red-bean.com/en/1.0/ch07s03.html) First, an externals definition can only point to directories, not files. > Second, the externals definition cannot point to relative paths (paths > like ../../skins/myskin). Third, the working copies created via the > externals definition support are still disconnected from the primary working > copy (on whose versioned directories thesvn:externals property was > actually set). And Subversion still only truly operates on non-disjoint > working copies. So, for example, if you want to commit changes that you've > made in one or more of those external working copies, you must run svn > commit explicitly on those working copies—committing on the primary working > copy will not recurse into any external ones. And, svn:externals does not have a prompt so everything will be checkout-ed for everyone by the externals definition. ks
