CVS or SVN for Vanilla project

MrNase

Sounds reasonable :) With the approach to help: http://limnos.csrd.uiuc.edu/notes/howtos/svn.html

jos

Another option: post to their mailing list http://subversion.tigris.org/servlets/ProjectMailingListList , 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).

jtyler

Right on Jos. I second that.

Jazzman

LOL @ jos

Bergamot

Mailing lists are evil

MrNase

They ARE the devil.. I just can't handle them.. Way too complicated :(

Bergamot

The SVN devs should just use Vanilla instead :D

MrNase

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 ;-)

Mark

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*

Mark

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.

Bergamot

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.

Mark

For the record, here is where I am at...

My apache2 conf file for mysvndomain.com is:

<VirtualHost 67.18.176.227:80>
        ServerName mysvndomain.com
        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
            </LimitExcept>
        </location>   
    </VirtualHost>

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 http://mysvndomain.com/svn/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 http://mysvndomain.com/svn/vanilla, 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 http://mysvndomain.com/svn/vanilla/trunk 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 (http://mysvndomain.com)

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.

Mark

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 mysvndomain.com 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.

Bergamot

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.

Minisweeper

/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 =\

Mark

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.

Bergamot

Understandable, but not having working permissions on the version control program doesn't prevent you from releasing a beta tonight.

Krak

I didnt mean to bring ya down, was just trying to be funny. :/

giginger

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?

MrNase

I knew it.. I woke up and thought mark had so much trouble with SVN that he hasn't released the new version :(