Re: Getting source for apacheds-1.0.3-SNAPSHOT
Le 10/9/12 4:15 PM, Johnson, Wayne a écrit : Thanks for the fast response. I'm afraid I'm still a bit of a novice at using svn. I was able to checkout the project pom, apacheds and daemon source with no problem. I did modify your commands slightly: svn co http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0@647850 apacheds svn co http://svn.apache.org/repos/asf/directory/daemon/branches/1.0@559605 daemon svn co http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0-with-dependencies@647850 . I was not able to check out the shared source. I get the error: svn co http://svn.apache.org/repos/asf/directory/shared/branches/1.0@559606 shared svn: URL 'http://svn.apache.org/repos/asf/directory/shared/branches/1.0' doesn't exist My bad : svn co http://svn.apache.org/repos/asf/directory/shared/branches/0.9.5@559606 is the correct link (the copy/paste kept 1.0 instead of 0.9.5 at the end) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
RE: Getting source for apacheds-1.0.3-SNAPSHOT
OK, I finally got it to compile. I'm posting this for posterity.
There were some incompatibilities (apparently) with these revisions. I ended
up using the svn -r date function to target the date our snapshot was built:
svn co
http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0-with-dependencies@647850
-r '{2007-08-09}' .
svn co http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0@647850
-r '{2007-08-09}' apacheds
svn co http://svn.apache.org/repos/asf/directory/shared/branches/0.9.5@559606
-r '{2007-08-09}' shared
svn co http://svn.apache.org/repos/asf/directory/daemon/branches/1.0@559605 -r
'{2007-08-09}' daemon
mvn clean install -DskipTests=true
There were a few unit tests that failed, but I believe these were innocuous.
Thanks for the help. I've learned quite a bit out of this exercise.
-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Tuesday, October 09, 2012 9:39 AM
To: users@directory.apache.org
Subject: Re: Getting source for apacheds-1.0.3-SNAPSHOT
Le 10/9/12 4:15 PM, Johnson, Wayne a écrit :
Thanks for the fast response. I'm afraid I'm still a bit of a novice at
using svn.
I was able to checkout the project pom, apacheds and daemon source with no
problem. I did modify your commands slightly:
svn co
http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0@647850
apacheds svn co
http://svn.apache.org/repos/asf/directory/daemon/branches/1.0@559605 daemon
svn co
http://svn.apache.org/repos/asf/directory/apacheds/branches/1.0-with-dependencies@647850
.
I was not able to check out the shared source. I get the error:
svn co
http://svn.apache.org/repos/asf/directory/shared/branches/1.0@559606
shared
svn: URL
'http://svn.apache.org/repos/asf/directory/shared/branches/1.0'
doesn't exist
My bad :
svn co http://svn.apache.org/repos/asf/directory/shared/branches/0.9.5@559606
is the correct link (the copy/paste kept 1.0 instead of 0.9.5 at the end)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
build monday from trunk very slow for ldif import
Hi, I'm still trying finish the testing of all the Password policy work Karin did over the weekend but I have another issue that's come up. Ldif imports are extremely slow. During our testing, we often delete the entire partition directory to start fresh. When the server starts, it lays down the partition and .db files as defined config.ldif. Anyway, we used to import (via studio) an ldif file with 80k entries and it would load about 90 entries per second. That was great! With this build it's going at about 4-5 entries per second. We noticed is that previously, the partition .db files would not change (on disk) until after the ldif import was complete. Then when we stopped the server, it was like the entire import got flushed to the disk at once. The files would go from 20K to 400MB. With this build, it seems to be updating the files as it goes. Could this be the reason? Also, this is the first build I noticed the .lg files in the partition directory. I think they're there for journaling but don't know if that's an option something new? We removed all the password policy Attributes from my ldif file thinking that was slowing it down but it's essentially the same performance. Below is my partition and all the indexes are set like the one I included. Any changes that would affect this in the last few weeks. Anyone else seeing this? Thanks! dn: ads-partitionId=cpro,ou=partitions,ads-directoryServiceId=default,ou=config objectclass: top objectClass: ads-base objectclass: ads-partition objectclass: ads-jdbmPartition ads-indexes: apacheRdn ads-indexes: apacheSubLevel ads-indexes: apachePresence ads-indexes: apacheOneLevel ads-indexes: apacheOneAlias ads-indexes: apacheSubAlias ads-indexes: apacheAlias ads-indexes: entryCSN ads-indexes: krb5PrincipalName ads-indexes: objectClass ads-indexes: ou ads-indexes: uid ads-indexes: employeeNumber ads-indexes: displayName ads-indexes: cn ads-indexes: mail ads-indexes: roomNumber ads-indexes: pwdPolicySubEntry ads-indexes: member ads-indexes: description ads-indexes: givenName ads-indexes: sn ads-indexes: administrativeRole ads-partitionSuffix: o=cpro ads-jdbmpartitionoptimizerenabled: TRUE ads-partitioncachesize: 100 ads-partitionsynconwrite: TRUE ads-partitionid: cpro ads-enabled: TRUE #index example, they're all like this..HasReverse=FALSE dn: ads-indexAttributeId=uid,ou=indexes,ads-partitionId=cpro,ou=partitions,ads-directoryServiceId=default,ou=config ads-indexattributeid: uid ads-indexHasReverse: FALSE ads-indexcachesize: 100 objectclass: ads-index objectclass: ads-jdbmIndex objectclass: ads-base objectclass: top ads-enabled: TRUE
