|
[
Permlink
| « Hide
]
Brett Porter added a comment - 08/Feb/05 06:55 AM
the reason for the current layout is that each subproject has a different lifecycle.
Fair enough, but it looks like you might be going a bit far into decoupling things and thus creating more complexity than necessary in the structure.
It's nearly like instead of having java 'packages' you have been creating sub-modules with a different lifecycle. I'm not sure there will be such a different lifecycle between sub-modules, especially as there are no resources to do backward compatibility testing and mixing. (there is no QA so it's always HEAD) Therefore you will nearly always tag each trunk at the same time...which is exactly the same has having all under the same trunk, except that it is much more manageable..you might even get most of them into the main source tree :) Bumping this again. Directory is becoming more and more a mature project in term of code, that would be helpful to be able to checkout only module trunks in order to make it easier to follow the project and minimize bandwidth/disk storage. Checking out Gigabytes of code is no cool :)
I suggest creating 'trunks' as http://svn.apache.org/repos/asf/directory/trunks Then do: set SVN_EDITOR=yourfavoriteeditor svn propedit svn:externals trunks Add the defintion below, save and quit: apacheds https://svn.apache.org/repos/asf/directory/apacheds/trunk asn1 https://svn.apache.org/repos/asf/directory/asn1/trunk authx https://svn.apache.org/repos/asf/directory/authx/trunk clients/kerberos https://svn.apache.org/repos/asf/directory/clients/kerberos/trunk clients/ldap https://svn.apache.org/repos/asf/directory/clients/ldap/trunk naming https://svn.apache.org/repos/asf/directory/naming/trunk network https://svn.apache.org/repos/asf/directory/network/trunk protocol-providers/changepw https://svn.apache.org/repos/asf/directory/protocol-providers/changepw/trunk protocol-providers/dhcp https://svn.apache.org/repos/asf/directory/protocol-providers/dhcp/trunk protocol-providers/dns https://svn.apache.org/repos/asf/directory/protocol-providers/dns/trunk protocol-providers/kerberos https://svn.apache.org/repos/asf/directory/protocol-providers/kerberos/trunk protocol-providers/ldap https://svn.apache.org/repos/asf/directory/protocol-providers/ldap/trunk protocol-providers/ntp https://svn.apache.org/repos/asf/directory/protocol-providers/ntp/trunk shared/kerberos https://svn.apache.org/repos/asf/directory/shared/kerberos/trunk shared/ldap https://svn.apache.org/repos/asf/directory/shared/ldap/trunk sitedocs https://svn.apache.org/repos/asf/directory/sitedocs/trunk standalone https://svn.apache.org/repos/asf/directory/standalone/trunk testsuite https://svn.apache.org/repos/asf/directory/testsuite/trunk Now you can do a: svn update http://svn.apache.org/repos/asf/directory/trunks Hey Stephane! This is certainly an option. However I think there might be a better approach to this. Take a look at this Confluence page here:
http://docs.safehaus.org/display/APACHEDS/New+Project+Layout It explains a new structure that is used by felix which makes a lot of sense. If we use this then the use of svn:externals are not necessary. WDYT? Yes, moving everything in the same trunk leads to what I was suggesting in my initial issue comments in February.
I'm fine with this, even though I'm not quite sure about the tagging policy, but with subversion you can change the layout anytime, so everything will be refined with time. +1 :) I think this has been done somehow.
Branches are using svn:externals to point on shared and mina subprojects |
||||||||||||||||||||||||||||||||||||||||||||||||||