22 replies to this topic

[ambershee]

Hi Guys,

There was a lot of chat about getting some sort of version control software up and running a while back - did anything come of that? The reason I'm asking is that I'm now very interested in using Subversion for a current project as managing code between three individuals without it can beb potentially quite frustrating.

I'm also wondering if it will be possible to scrub my old wiki and set up a new one, as well as Mantis for bug tracking?

Thanks!

AmberZ

[Banshee]

The subversion was installed in the server in the middle of the year.

Here's a sample of it working:
http://svn.ppmsite.com

[ambershee]

The front end is nice, I assume we can use most SVN clients (e.g Tortoise) merrily?

[Banshee]

Yea, Tortoise works very well and it is the one I recommend.

[jnengland77]

Ambershee, when I return to uni, and also after I'm feeling better (cold and sinus infection...) I will set one up for you.

~jnengland77

[ambershee]

Sounds great - there's no huge rush

[Jeeves]

Buts hes the Server Technician/Server Lord/Server Assistant, and with that many job titles he needs as much work as possible

[jnengland77]

Alright I need some information. Domain name, and subdomain if there is one. Who's going to be using it. It can be priviate (no frontend) and has a separate username/password file; or is it going to be shared by a certain group of people like a certain mod team and has a separate username/password file (websvn frontend optional). Or public which is like shared, but will have a global username/password file. Sounds like you would want the shared option and if this code you are working on can be public than websvn can be added.

~jnengland77

[ambershee]

Okidoki.

We're sheelabs (gamemod.net), and any reasonable address is fine. We'd like it shared, as that's the most useful way of organising it, and a websvn front end would be nice but isn't necessary. Additional users would accumulate over time, as the team changes, so if I'm unable to add users myself I'll have to keep bugging - I'll PM a set of user names to cover the current core later if you wish, but for now you can just include myself. Let me know if you need anything else.

We'll also need a fresh MySQL database for a new wiki - if you can scrub the old one that's fine, but replacing it is also fine, I can just delete and reinstall media wiki

[jnengland77]

Sent you a PM. Someone else will have to deal with the wiki. I'm not sure how to do it from WHM.


Good luck,

jnengland77

[ambershee]

Thanks very much

[ambershee]

Bit of a bump - any news on resetting up that wiki? We could do with it at some point as it's supposed to be our primary means of collaborating and communicating.

Also, committing to SVN seems to be painfully slow, what are the upload speeds like? It might better help me work out what sort of chunks I should be committing at any given time.

[Banshee]

It works fast here and I'm using it daily.

[Bart]

What kind of files are you putting on it? These systems weren't made with very large binary files in mind.

[ambershee]

There will be some large binary files. We're working with Unreal 3 - asset packages and maps in particular can easily become very large, but they still need to be versioned alongside code, so we'll have to make do.

[Banshee]

The largest file I'm using is an executable file of the program. It should be smaller than a megabyte.

[ambershee]

Hehe, the UE3 runtime executable itself is nearly 40mb >.<

Some of our binary files could potentially get around 100mb+.

[ambershee]

Any update on getting a database running for the wiki? The staff are getting restless!

[Jeeves]

Nag me on MSN

[Bart]

about large files:

Be patient with large files

A nice feature of Subversion is that by design, there is no limit to the size of files it can handle. Files are sent "streamily" in both directions between Subversion client and server, using a small, constant amount of memory on each side of the network.

Of course, there are a number of practical issues to consider. While there's no need to worry about files in the kilobyte-sized range (e.g. typical source-code files), committing larger files can take a tremendous amount of both time and space (e.g. files that are dozens or hundreds of megabytes large.)

To begin with, remember that your Subversion working copy stores pristine copies of all version-controlled files in the .svn/text-base/ area. This means that your working copy takes up at least twice as much disk space as the original dataset. Beyond that, the Subversion client follows a (currently unadjustable) algorithm for committing files:

* Copies the file to .svn/tmp/ (can take a while, and temporarily uses extra disk space))
* Performs a binary diff between the tmpfile and the pristine copy, or between the tmpfile and an empty-file if newly added. (can take a very long time to compute, even though only a small amount of data might ultimately be sent over the network)
* Sends the diff to the server, then moves the tmpfile into .svn/text-base/

So while there's no theoretical limit to the size of your files, you'll need to be aware that very large files may require quite a bit of patient waiting while your client chugs away. You can rest assured, however, that unlike CVS, your large files won't incapacitate the server or affect other users.