2) Easy upload, push one button and update each day with the new build.
3) Allow easy access for everyone in the community.
Downloading the SVN is open to everyone.
To get rights to upload and commit to the SVN you must first have created a patch a change and had it vetted by one of the people in charge of the SVN.
The reason behind this is simple. You have to show that you know how to make changes before we give you permission to make changes. This should also stop people from trying to trash everyone else's work. As it would require them to actually work first before getting access.
3) Allow easy access for everyone in the community.
A little harder - but feed the read-only checkout url to tortoise and it'll get you the latest source. Anyone who can make sense of the code should be comfortable with that. Most repos will also let you browse the code from the web, Google included.
A long time ago I set up code.google.com/p/otherworldtoday/ but am not convinced that it was the best choice. And I am not an expert on SVNs. Your comments and help would be appreciated.
It should be more or less the same as any other svn provider - probably with better uptime. I've used sourceforge (good, but the application process is a bit tedious and you have to use an explicit open source licence); Assembla.org (don't recommend - the size of the .fla will put us into the level of disk usage where they start getting arsey about things) and the PPG repo which is admined by Dagoth. I've also got local svn repos on an old laptop for my personal projects.
All in all, there's not a lot of difference between any of them. The difference is in the client; I suggest tortoise, or command line svn, depending on what you're most comfortable with.
If you don't want to use svn, I'd probably plump for git. But svn for my money.
So Doc and I had a discussion in the Blog Comments thread, and kind of came to an agreement that we could use google code for now, and it as well as the February open source as a test to allow us to get familiar with SVN. Naturally we would need to be added to the project user list.
They're pretty intuitive so I won't bother explaining what they do. Things such as branch, merge and tag I understand how they work on paper, but really need to actually work with them to give better explanations. Suffice to say. branch splits code, so you you can work on things without editing the original (daisy's code). Merge adds your changes to the original code, or Vice versa. Tag I guess lets you note key/important milestones. (such as alpha, beta, version 1.0 etc.)
Sent you a PM Daisy. Hey Doc, you're using the new years open source for your loader tests right? After Daisy adds us to the group I'm going to go ahead and test commit the "vanilla" 1/3/11 one from the download section. I assuming editing the folder in trunk will be pretty straightforward once we have edit rights correct?
Sent After Daisy adds us to the group I'm going to go ahead and test commit the "vanilla" 1/3/11 one from the download section. I assuming editing the folder in trunk will be pretty straightforward once we have edit rights correct?
Should be - check out a writeable version of the code, copy in the current version, add new files to svn so they get updated (you'll see a "?" on the file icons) and commit.
Ok so this is what I would suggest doing first if you are going to be setting up repositories on google code. Each individual person who is working on an svn repository needs to get their own branch including daisy. Setup an additional(if not setup already) branch for the trunk. This way each individual can commit and work on separate versions of the code.
Otherwise you end up with a very bad code revision problem with code. if your not already familure with it, this is how it goes: Daisy uploads some recent changes, and she forgot to add something. Docclox updates, sees if everything works, commits to the same branch. Daisy remember she forgot to add something fixes it updates commits. Eventually 8 -20(maybe more) revisions down the road the whole project starts throwing errors. Now because its not strictly one persons code, its extremely hard to track down what revisions and code to fix it.
If everyone has separate repositories and uploads strictly to those repositories you have a much cleaner repository structure to revert commits and find bugs.
Meaning that releases only, should be committed to trunk. To that fact daisy should have the final say to those commits.
Just keep in mind that the more people working on this the more you of a problem with merging repositories and keeping everything stable.
zenzou Merge, picks an additional repository to merge into your working copy that have a common trunk.'
Tagging is at its core a branch of the repository, a snapshot of a current working version. Never put a tag within your code or it will double the folder size. These are normally reserved for archival purposes, mostly used server side.
If something isnt clear or you have other svn questions, please ask.
If you're having space problems with the address, try using the %20 html character for space, the same as would show in the address bar of your browser. That should work.
Definitely use TortoiseSVN, it makes things significantly easier than any of the other clients for windows.
Finaru's suggestions make sense - if you're all working on the same branches you'll end up with merge conflicts, and these range from easy to painful to correct. At least if you're all working on your own branches this becomes a set task on a regular schedule. You'll still end up with merge conflicts but it should be easier to manage.
Zenzou - the subdirectories should also update as long as you update the root folder in its entireity (rather than specific files).
Will the contents of the subs folders, such as assistant, girls, etc., sync at the root level,in their correct paths or not even sync at all?
Yes if you checkout the trunk, add the files(remember to add new files, svn is really bad for recursively checking if the file structure has changed.) This should recursively add all of the files into the .svn folders. Next update and commit your changes.
Once this is done you will have to make sure not to change your folder structure or you will possibly loose your revisions.
Might have been because I had it open. Went ahead and deleted it for you.
Yeah okay, so disregard the problems I said I had, product of not being familiar with Tortoise; I had it correctly the first time. Obviously if it said something doesn't exist then it's my fault for not seeing that. I went ahead and a made folder under branch with my handle and committed 1/3/11 open source to it. Just so everyone knows I deleted all the pre-compiled .swf files, so if someone needs to know what the original contents were, let me know and I'll post a list.