About version control software
Author
I'm working in a company that is not related to videogames. In my company the vcs used is Visual Source Safe. Why my company uses VSS when everywhere I read that is something to get away from, I have no clue. But what it puzzles me even more is that VSS has a limit for a database of 4GB. My company uses a lot of graphics (one of the projects that I am managing has near 2GB), so only the code goes into VSS.
Now, couple of questions:
1 - does any other vcs have a size limit? I have not seen references of such thing for Perforce, CVS or SVN. Nor it appears in any comparison table. But I am asking just in case I have missed it.
2 - for those who work in large projects. Do you put every file of the project, code and resources, inside the vcs? As I said my company does not, and to me it screams "Wrong!!!".
Thank you for your help.
Akira
1) VSS is TERRIBLE. IIRC not even Microsoft uses it internally; that should tell you something. Subversion is good and free; perforce is better and costs money.
2) Yes, everything goes into source control: code, content, whatever. We have to split into 2 databases (we use perforce). Code goes in one, content in another. But that's for machine performance reasons. We have multiple projects' source in a single depot, then each project gets their own depot for content.
-me
2) Yes, everything goes into source control: code, content, whatever. We have to split into 2 databases (we use perforce). Code goes in one, content in another. But that's for machine performance reasons. We have multiple projects' source in a single depot, then each project gets their own depot for content.
-me
My condolences. I've used several source control system and VSS is by far the worst choice available. Not even Microsoft use VSS.
And yes, your graphics should be under source control unless they are generated during the build. _Every_ source file used to build your product should be versioned and labelled with your code.
I guess all you can do is keep trying to convince your place to move to a real version control system. Look up the field of "configuration management" and try and explain to them why it is important.
And yes, your graphics should be under source control unless they are generated during the build. _Every_ source file used to build your product should be versioned and labelled with your code.
I guess all you can do is keep trying to convince your place to move to a real version control system. Look up the field of "configuration management" and try and explain to them why it is important.
To correct something, while "visual source safe" supports only 4 GB databases, "Team Foundation" actually supports Terabytes of data. That said, I tried to find information on SVN limitations and couldn't find anything. I suspect the limit is quite large, but you could perform tests with obscenely large files with an SVN client to see what happens. I did find this link though:
http://polymorphicpodcast.com/shows/subversion/
I saw this link about perforce limitations:
http://kb.perforce.com/?article=53
I couldn't find anything on CVS
http://polymorphicpodcast.com/shows/subversion/
I saw this link about perforce limitations:
http://kb.perforce.com/?article=53
I couldn't find anything on CVS
I've remember reading something about another one, supposedly better than svn, and free, called Git. I've only ever used svn. Have any of you tried Git?
And would you say that, for a hobbyist developer, versioning control software like this is necessary?
And would you say that, for a hobbyist developer, versioning control software like this is necessary?
Quote:
And would you say that, for a hobbyist developer, versioning control software like this is necessary?
No. In exactly the same sense that an IDE isn't "neccessary."
(By which I mean, sure, you can get by without it -- you can even do some pretty excellent work without it -- but why? There are pretty much no disadvantages to getting cozy with a SCM of your choice.
SVN works pretty well for free and has a nice explorer integration (tortoise). Perforce kicks it into touch though for professionalism. Alienbrain could be cool but I have yet to see a project hook into its best features. CVS was pretty good but I believe its replaced by SVN.
I was hoping that VSS would have improved in the years since I was bruised by it.
In my unnamed studio [and the one I worked at previously] we only put source assets under revision control. This works fine so long as there is a reasonably streamlined process for distributing any generated resources.
If someone else was paying I would pick Perforce and if not then SVN with Tortoise. I would continue to keep generated resources out of revision control (except perhaps a "latest release") and key them by tool versions.
P.s. There are rumors of a Linus Loved RVS call GIT - no personal experience of this but would be interested in what other people knew: http://git.or.cz/
I was hoping that VSS would have improved in the years since I was bruised by it.
In my unnamed studio [and the one I worked at previously] we only put source assets under revision control. This works fine so long as there is a reasonably streamlined process for distributing any generated resources.
If someone else was paying I would pick Perforce and if not then SVN with Tortoise. I would continue to keep generated resources out of revision control (except perhaps a "latest release") and key them by tool versions.
P.s. There are rumors of a Linus Loved RVS call GIT - no personal experience of this but would be interested in what other people knew: http://git.or.cz/
Quote:Original post by jpetrieQuote:
And would you say that, for a hobbyist developer, versioning control software like this is necessary?
No. In exactly the same sense that an IDE isn't "neccessary."
(By which I mean, sure, you can get by without it -- you can even do some pretty excellent work without it -- but why? There are pretty much no disadvantages to getting cozy with a SCM of your choice.
I'd be blind without it, even at home on code that only I touch.
The last time I tried using git on Windows, admittedly this was a few months or more ago, it was something of a mess. Long story short, using git on NTFS worked fine, but when I tried transferring the system onto a FAT32 external drive, the system wouldn't work at all, and I had to end up recompiling git to work with FAT32. Unfortunately, the change necessary made git run very slowly.
I understand that the current git binary distribution for Windows/cygwin now works with FAT32 out of the box. However, I don't know if the speed issue has been addressed. I personally have no plans to retry it on Windows until they get a freestanding (non-cygwin or MSYS dependent) build working.
On the whole, for Windows development in a single user or small group environment, I prefer SVN with TortoiseSVN. It's free and it pretty much just works, though I admit I never have tried particularly large repositories or files with it.
I understand that the current git binary distribution for Windows/cygwin now works with FAT32 out of the box. However, I don't know if the speed issue has been addressed. I personally have no plans to retry it on Windows until they get a freestanding (non-cygwin or MSYS dependent) build working.
On the whole, for Windows development in a single user or small group environment, I prefer SVN with TortoiseSVN. It's free and it pretty much just works, though I admit I never have tried particularly large repositories or files with it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
