Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

CVS or SVN for Vanilla project



  • Options
    Sounds reasonable :) With the approach to help:
  • Options
    Another option: post to their mailing list , take a deep breath and let your wife give you a massage. Relax afterwards with a movie. Don't check the mailing list before you're entirely relaxed again (today is certainly forbidden).
  • Options
    Right on Jos. I second that.
  • Options
    LOL @ jos :)
  • Options
    Mailing lists are evil
  • Options
    They ARE the devil.. I just can't handle them.. Way too complicated :(
  • Options
    The SVN devs should just use Vanilla instead :D
  • Options
    The only way to tell them is via the mailing list. A kind of vicious circle, isn't it? :-D Anyway I noticed the SVN server has been removed..? The Url gives me a 404 :) Don't get me wrong, Iam always way too impatient ;-)
  • Options
    MarkMark Vanilla Staff
    The security was totally borked, so I wiped the whole thing and installed elsewhere. I'm not announcing it publicly until it works, and it still does not. I've got some colleagues looking into it right now to see if they can impart any wisdom. *prays*
  • Options
    MarkMark Vanilla Staff
    Well, they say they'll have to get back to me tomorrow. So, unless anyone here has any great ideas, it looks like I didn't make that "End of November" deadline.
  • Options
    edited November 2005
    You could always just toss the files in a rar... ;-) I mean SVN trees are nice for a variety of reasons, none of which are really immediate.
  • Options
    MarkMark Vanilla Staff
    For the record, here is where I am at...

    My apache2 conf file for is:
            DocumentRoot /applications/lussumo/mysvndomain/
            ErrorLog /applications/webalizer/mysvndomain/error.log
            CustomLog /applications/webalizer/mysvndomain/access.log combined
            <location /svn>
                Order allow,deny
                Allow from all
                DAV svn
                SVNParentPath /subversion
                # our access control policy
                AuthzSVNAccessFile /etc/apache2/auth-files/lussumo-svn-authzfile
                # how to authenticate a user
                AuthType Basic
                AuthName "Lussumo Subversion Repository"
                AuthUserFile /etc/apache2/auth-files/lussumo-svn-authfile   
                # only authenticated users may modify the repository
                <LimitExcept GET PROPFIND OPTIONS REPORT>
                    Require valid-user

    As you can see from the "location" declaration, I've created a folder in the root of my system called "subversion". I've chowned that folder to www-data:www-data (the apache user/group on Debian). I su'd to www-data and created a vanilla repository within that folder.

    I have created the AuthzSVNAccessFile as follows:

    # Directory specific authorization control [groups] owner = mark vanilla-developers = mark [/] @owner = rw [vanilla:/] @vanilla-developers = rw * = r

    My idea here is that I want everyone to be able to browse the repository, but I only want the owner or vanilla-developers to be able to read AND write to the repository. I've currently got myself as the owner and I've only added myself as a developer. Others will follow once I get things working properly.

    I've already got a system account for "mark". When I created my /etc/apache2/auth-files/lussumo-svn-authfile file, I gave "mark" the same password as the system "mark" account.

    Once all of that was done, I did an "apache2ctl graceful" on the server.

    Then I went to the repository on my local machine (via command prompt) and ran this:

    svn import vanilla -m "Initial Import"

    It did NOT prompt me for my password. I have tried this multiple times and I can't remember if it prompted me for my password the first time or not. I read through the SVN docs and found that yes, it does store a cache of authenticated users. I changed the svn config so that it should no longer store cached authentications (it should prompt for a username and password every time) just because I wanted to be sure that it wouldn't be open to everyone to modify. The docs said that even after you make those changes, it doesn't work for authenticated users who were already authenticated and you have to go delete those authentications. I went in to where it said in the docs they would be, and there was nothing there at all. So, I don't really know what to make of that.

    So, I guess this is the first problem: it never prompted me for authentication.

    At that point if I browsed to, it showed me the repository just fine.

    After that I went to another folder on my local machine and checked out the repository's trunk folder

    svn checkout vanilla

    That worked fine and gave me everything I needed - again, without requiring a username and password (which is what I wanted).

    Here is the second problem: I then modified a file and did an svn commit -m "Testing File Modifications". It did NOT prompt me for a username or password and it did the commit successfully.

    Here is the third problem: I then created a phpinfo.php file in the root of my local vanilla folder. I did an "svn add phpinfo.php" and that worked. Then when I tried to commit the repository, I got this error:
        C:\applications\subversion\vanilla>svn commit -m "Testing New File"
        Adding         phpinfo.php
        svn: Commit failed (details follow):
        svn: PROPFIND request failed on '/svn/vanilla/trunk/phpinfo.php'
        svn: PROPFIND of '/svn/vanilla/trunk/phpinfo.php': 302 Found (

    After googling a LOT, all I can come up with is that this error happens when your virtual server's documentroot and your location declaration's folder overlap so apache doesn't know what to do with the file. And that obviously isn't the case here since my settings do not overlap.
  • Options
    MarkMark Vanilla Staff
    I'm pretty confused and frustrated. Their errors are so non-descript, and their documentation doesn't include any troubleshooting at all - it's all just "do it this way and it will work", but as you can see, it's not really working like it should.

    There you have it. Oh, and isn't correct, I know. I just don't want you guys to know where I've put it (yet). I'll announce it later when everything is working.
  • Options
    Even if someone commits crap overwriting one of the files, it would still keep copies of all the old versions; the ability to rollback the whole program is one of the key benefits to version control systems.
  • Options
    /me really wishes he could help. The only wisdom i can suggest is to dump apache2 cause it seems like a whole load more effort than apache1 =\
  • Options
    MarkMark Vanilla Staff
    I don't want to have to concern myself with x people performing modifications to the core. For the time being I'd prefer to concern myself with a select few who have permission to modify - and everyone else can just read.
  • Options
    Understandable, but not having working permissions on the version control program doesn't prevent you from releasing a beta tonight.
  • Options
    I didnt mean to bring ya down, was just trying to be funny. :/
  • Options
    I have no knowledge in this sort of thing.

    The only overlapping thing I can see is the system account and developer account both being called Mark and having the same password. Unless I read it wrong?
  • Options
    I knew it.. I woke up and thought mark had so much trouble with SVN that he hasn't released the new version :(
This discussion has been closed.