Blog

  • Re: Error Validating Certificate

    Yes it is true we build and bundle our own OpenSSL library. I’ve opened a
    ticket internally to bundle a default trusted certificates list with out
    package.

    Mark

    On 3/5/09 12:40 PM, “Raj Singh” wrote:

    > bench@host30:/shares/perf/bench/examinator/trunk> /usr/local/bin/svn up
    > Error validating server certificate for ‘https://svn.terracotta.org:443’:
    > – The certificate is not issued by a trusted authority. Use the
    > fingerprint to validate the certificate manually!
    > Certificate information:
    > – Hostname: svn.terracotta.org
    > – Valid: from Fri, 01 Dec 2006 23:06:57 GMT until Tue, 01 Dec 2009 23:06:57
    > GMT
    > – Issuer: Equifax Secure Certificate Authority, Equifax, US
    > – Fingerprint: 32:14:3f:9f:ac:de:b1:a9:c7:1f:89:a3:7f:73:a4:25:a6:a4:3c:84
    > (R)eject or accept (t)emporarily? t
    > Authentication realm: Terracotta Realm
    > Password for ‘bench’:
    > Authentication realm: Terracotta Realm
    > Username: bench
    > Password for ‘bench’:
    > Authentication realm: Terracotta Realm
    > Username:
    >
    >
    > Actually, this is a question about SSL libraries. Collabnet subversion looks
    > like it links against its own SSL libraries and not those of the system.
    >
    > $ ldd /usr/local/bin/svn | egrep “ssl|crypto”
    > libssl.so.0.9.8 => //opt/CollabNet_Subv​ersion/lib/libssl.so​.0.9.8
    > (0x00002b9dd1332000)
    > libcrypto.so.0.9.8 =>
    > //opt/CollabNet_Subv​ersion/lib/libcrypto​.so.0.9.8 (0x00002b9dd1479000)
    >
    > My binaries that are linked against the system OpenSSL libs have no trouble
    > with the certificate authority (which is Equifax/Geotrust BTW, so it’s not
    > like it’s even some self-signed CA)
    >
    > ——————————————————
    > http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=30
    > 3791

  • Subversion apache2 nis authentication

    I have installed subversion 1.5.5-1 on CentOS 4.4.

    I followed http://www.yolinux.com/TUTORIALS/LinuxTutorialApacheAddingLoginSiteProtection.html#NIS

    I followed all the steps except I downloaded and installed “Apache2-AuthenNIS-0.15” instead of “Apache-AuthenNIS-0.13”.

    I added following in /etc/opt/CollabNet_Subversion/conf/httpd.conf.

    # Code for nis authentication

    AuthType Basic
    AuthName “Enter your login ID:”
    PerlAuthenHandler Apache2::AuthenNIS
    PerlSetVar AllowAlternateAuth no
    require valid-user

    Now, svn configuration fails with the following error:

    Stopping CollabNet Subversion: Syntax error on line 128 of /etc/opt/CollabNet_Subversion/conf/httpd.conf:
    Invalid command ‘PerlAuthenHandler’, perhaps misspelled or defined by a module not included in the server configuration
    Starting CollabNet Subversion: Syntax error on line 128 of /etc/opt/CollabNet_Subversion/conf/httpd.conf:
    Invalid command ‘PerlAuthenHandler’, perhaps misspelled or defined by a module not included in the server configuration

    When I try to install mod_perl2 (mod_perl-2.0.4):

    cd mod_perl-2.0.4
    perl Makefile.PL

    Please provide a full path to ‘apxs’ executable
    (press Enter if you don’t have it installed): /opt/CollabNet_Subversion/bin/apxs

    [ error] Unable to open /opt/CollabNet_Subversion/include/ap_release.h: No such file or directory
    [ error] Unable to determine server version, aborting.
    [ error] Invalid MP_APXS specified?

    I can not file /opt/CollabNet_Subversion/include directory in Collabnet’s installation.

    Please help.

  • @clairecmc given the insignifi…

    @clairecmc given the insignificant amounts of $$$ devoted to earmarks, why is this even an issue?

  • @DBowen I hope you can reform …

    @DBowen I hope you can reform the initiative process. it’s too easy for well-funded orgs to game… but do it after we repeal prop 8 🙂

  • @hunleyd not that there’s anyt…

    @hunleyd not that there’s anything wrong with that… 😉

  • @hunleyd not to mention, I don…

    @hunleyd not to mention, I don’t send my @ replies to twitter from identica, so it looks like you’re talking to yourself

  • @lcooney great… that vid was…

    @lcooney great… that vid was already DMCA’d 🙁

  • Sparse Directories, Now With Exclusion

    “cmpilato ❤ sparse directories”

    If I had a dollar for every time I’ve typed that… well, you and I could at least spring for some Fazoli’s fast-food Italian. Okay, I admit that the emotion doesn’t always drive me to public expression, but that in no way diminishes my fondness for this feature.

    Introduced in Subversion 1.5, sparse directory support is one of a few features from that release (besides merge tracking and foreign repository merges) that I’ve fully integrated into my day-to-day activities. I dig organization. I tend to keep a pretty neat home directory. But I routinely work on several different pieces of software, and at any given time, I’m tracking several different development branches in each of those pieces of software. Were I not using sparse directories, my “projects” directory would look something like this:

    $ ls ~/projects
    subversion/		      svnbook/		 viewvc-1.0.7/
    subversion-1.5.x/	      thotkeeper/	 viewvc-1.0.x/
    subversion-1.6.x/	      thotkeeper-0.3.0/  viewvc-1.1.0-beta1/
    subversion-http-protocol-v2/  viewvc/		 viewvc-1.1.x/
    $
    

    On the positive side of things, I could quickly update all my working copies by simply running svn update ~/projects/*.

    But those of you who have command-line completion as hard-wired into your habits as I do will immediately notice that so many common directory prefixes does a useless completion environment make. And not using common prefixes? Well that’s just barbaric.

    Fortunately, sparse directories has given me a whole new perspective on working copy organization. Now, my projects directory contains (gasp!) only projects, and looks like this:

    $ ls ~/projects
    subversion/  svnbook/  thotkeeper/  viewvc/
    $
    

    Those directories are sparse checkouts of the root directories of their respective project repositories. Beneath them are (at least) “trunk” directories, probably “branch” and some of its children, and maybe even “tags” with some of its children in certain cases. svn up ~/projects/* still works, and my working copy topology matches that of the repositories.

    I won’t go into the details of how sparse checkouts works here — I’ve already documented the Subversion 1.5 implementation of them in the second edition of Version Control With Subversion (which you can read at http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html). The point of this blog post is to tell you about how Subversion 1.6 improves this feature in a key way.

    In Subversion 1.6 (slated for release Any Day Now), the --set-depth parameter to svn update has grown a new value — exclude. This value tells Subversion to exclude the target from the working copy, immediately and until further notice. Prior to Subversion 1.6, if a branch I was working on was no longer of interest to me, I couldn’t easily remove it from my working copy. If I simply deleted it, it would return the next time I updated the working copy. If I svn delete‘d it, the branch remained as a local modification forever. (Unless, of course, I accidentally committed it, which brought a whole different sort of trouble to my doorstep. Angry peers. Pitchforks and torches. It was a mess — you don’t want to go there.) The new exclusion mechanism in Subversion 1.6 is the Right Way To Do It.

    Say I no longer care about what’s going on some directory of one my project working copies. Maybe I don’t care about the Subversion project’s website any more. Well, with this new exclusion feature, I can tell Subversion to remove that directory:

    $ cd ~/projects/subversion/trunk
    $ svn update --set-depth=exclude www
    D         www
    $ ls www
    ls: cannot access www: No such file or directory
    $
    

    Done deal. When I update my working copy in the future, I will not receive any changes aimed at that www directory. If I later decide that I once again care about that directory, I can “resubscribe” to it again:

    $ svn update --set-depth=infinity www
    A    www
    A    www/links.html
    A    www/testing-goals.html
    …
    A    www/tigris-permissions.html
    A    www/webdav-usage.html
    Updated to revision 36292.
    $
    

    Note that if you exclude a versioned directory that has some unversioned files in it, or some files with local modifications, Subversion handles this situation gracefully. All the files that aren’t safe to delete, Subversion leaves around, and of course leaves any intermediate directories required to reach those files, too.

    I hope this enhancement serves you as well as it has served me. What do you think? How are you using sparse directories to better organize your life?

  • @LisaH haha… I like all of t…

    @LisaH haha… I like all of those… AND House 🙂