I recently had a change in role in an UDK project I'm working on and it looks like its my job now to organize the group more effectively. (Long story)
One of the first things I want to do is get our code, UPKs, and raw content files in repositories.
The code repo needs to be able to store several revisions (10 or more).
The UPK repo needs to be able to store up to 3 revisions
The raw content repo only needs to store the most recent revision. (this is to prevent our repo from hounding all the space we have on the VPS)
I'm not going to be macho and say I've done this before. I'm organize groups for my day job and know that only using dropbox has to stop.
I'm not sure which repository program / programs will work best with what I need.
Can anyone make a suggestion? I'm unsure if SVN, Mercurial, or GIT can be limited for the number of revisions allowed per repo.
~Sean
Need advise on SVN / Mercurial / GIT
The entire point of version control is to store all revisions, which any of those will do effectively. It's important to note that Git and Mercurial are distributed version control systems while Subverson is not. That said, to specifically answer your question: according to some quick Google searches, the only VCS that supports "latest version only" functionality is Visual Sourcesafe.
There's nothing wrong with fully versioning your content. If you're concerned about space, Amazon S3 might be a viable solution. If you're just a small project, simply putting the content in the source repo isn't a terrible idea either.
As for the obvious flame war: if you need distributed capability, or simply like them, use Git or Mercurial. Otherwise, or if you've never used any of them, try them all and see which one you like best. Subversion is older, but a lot of people still love it so it isn't like using it is taboo.
There's nothing wrong with fully versioning your content. If you're concerned about space, Amazon S3 might be a viable solution. If you're just a small project, simply putting the content in the source repo isn't a terrible idea either.
As for the obvious flame war: if you need distributed capability, or simply like them, use Git or Mercurial. Otherwise, or if you've never used any of them, try them all and see which one you like best. Subversion is older, but a lot of people still love it so it isn't like using it is taboo.
All of them have similar functionality, it boils down to your needs and preferences. They all do far more than you are asking.
As for only hosting a few versions, that isn't the point of version control. The point is that you can get ANY version. You can get back what it looked like at any moment in time. You can tag revisions so you know that you packaged up revision 24723 to send to a potential client, or that you fixed a specific bug in revision 29412. You generally only work with the latest / current / head revision, depending on the terminology of your chosen package.
The first and most obvious question is if you actually need a distributed solution. The next question is if you have access to an always-available machine to run from -- which is related to the first question. Note that you can have your home PC work as an always-available machine using (free) dynamic dns systems. Next, what are the characteristics of your machines; what is their bandwidth and their storage?
I would recommend that if you don't need a distributed solution you stay away from them. The synchronization is another task on the to-do list, it can be slow after big submissions, and it can consume significant space on each machine as your repository grows.
It also depends on your usage pattern and what you put in it. At a corporate environment you would put EVERYTHING in version control, including all the build tools and compilers and SDKs, all visual and audio assets, which can quickly generate multi-terabyte repositories. They can reach millions of revisions after just a few years.
Although it could handle it, you wouldn't want to be using a distributed system to make your own local copy unless you have some mighty beefy disk arrays and a lot of spare bandwidth.
Conversely, if you have a widely distributed project where a single server source would be a problem, or proxies of a single source would similarly suffer from bandwidth issues, then a distributed system is an wonderful option. It can save a fortune on time and on individual bandwidth costs, and feel heaven-sent.
It is a personal or business decision, driven exclusively by your own needs and preferences.
Personally I use VisualSVN Server (free) one of my home machines, coupled with a (free) DynDNS account so I can access it at home or work or other locations.
As for only hosting a few versions, that isn't the point of version control. The point is that you can get ANY version. You can get back what it looked like at any moment in time. You can tag revisions so you know that you packaged up revision 24723 to send to a potential client, or that you fixed a specific bug in revision 29412. You generally only work with the latest / current / head revision, depending on the terminology of your chosen package.
The first and most obvious question is if you actually need a distributed solution. The next question is if you have access to an always-available machine to run from -- which is related to the first question. Note that you can have your home PC work as an always-available machine using (free) dynamic dns systems. Next, what are the characteristics of your machines; what is their bandwidth and their storage?
I would recommend that if you don't need a distributed solution you stay away from them. The synchronization is another task on the to-do list, it can be slow after big submissions, and it can consume significant space on each machine as your repository grows.
It also depends on your usage pattern and what you put in it. At a corporate environment you would put EVERYTHING in version control, including all the build tools and compilers and SDKs, all visual and audio assets, which can quickly generate multi-terabyte repositories. They can reach millions of revisions after just a few years.
Although it could handle it, you wouldn't want to be using a distributed system to make your own local copy unless you have some mighty beefy disk arrays and a lot of spare bandwidth.
Conversely, if you have a widely distributed project where a single server source would be a problem, or proxies of a single source would similarly suffer from bandwidth issues, then a distributed system is an wonderful option. It can save a fortune on time and on individual bandwidth costs, and feel heaven-sent.
It is a personal or business decision, driven exclusively by your own needs and preferences.
Personally I use VisualSVN Server (free) one of my home machines, coupled with a (free) DynDNS account so I can access it at home or work or other locations.
Author
Hey guys,
Thank you both for the sage advise. I'll give the short story. We had a lead coder who hosted our SVN for code only. He then disappeared and coincidentally at the same time our code became corrupt, unreadable. We didn't think anything about backups since the lead coder said he would handle that. Now we're starting over from scratch for the code... which is a terrible set back, but at least we have the UTClasses to start extending from again (yes, its another UDK project).
As the scope of the project changed, I became the lead. I decided to personally invested in a VPS server to run SVN (or GIT/Mercurial).
Since the VPS has a limited capacity (30GB), I need to be space conscious and only store a certain amount of revisions for the UPK's and raw assets.
I'm going to research SVN a bit more and see if it can be setup like that.
Thank you both for the sage advise. I'll give the short story. We had a lead coder who hosted our SVN for code only. He then disappeared and coincidentally at the same time our code became corrupt, unreadable. We didn't think anything about backups since the lead coder said he would handle that. Now we're starting over from scratch for the code... which is a terrible set back, but at least we have the UTClasses to start extending from again (yes, its another UDK project).
As the scope of the project changed, I became the lead. I decided to personally invested in a VPS server to run SVN (or GIT/Mercurial).
Since the VPS has a limited capacity (30GB), I need to be space conscious and only store a certain amount of revisions for the UPK's and raw assets.
I'm going to research SVN a bit more and see if it can be setup like that.
Figure out how to get sufficient space, rather than trying to limit your history -- the entire point of version control is that you can go back in time when you need to -- Unless you're psychic, you can't know ahead of time how much history will be enough in your time of need, so you need to have it all.
Author
ApochPiQ, because we needed a dedicated VPS for other reasons to consolidate costs. If we were to break up our services such as TS, Webhosting, and GITHub for business, we'd be paying more than what we're paying now with more auditing / financial tracking issues. Since I'm fronting the cost, I need to keep things as streamlined and organized as possible. Plus we've decided to not go with GIT, we decided that SVN is best for our specific needs.
Ravyne,
Like you said, I cannot predict how much space we will need, so how can I know how much is sufficient? This is why I want to control revision history. Are my requirements that demanding? Harddrives weren't always multi-terabyte and I can't imagine the designers of SVN wouldn't allow SOME control of revision history kept.
I do appreciate you both for trying to get me on the right path though. I'm not ignoring your advice, I'm just trying to apply it to my situation.
Ravyne,
Like you said, I cannot predict how much space we will need, so how can I know how much is sufficient? This is why I want to control revision history. Are my requirements that demanding? Harddrives weren't always multi-terabyte and I can't imagine the designers of SVN wouldn't allow SOME control of revision history kept.
I do appreciate you both for trying to get me on the right path though. I'm not ignoring your advice, I'm just trying to apply it to my situation.
You acknowledge that you can't know how much space you'll need, but at the same time want to apply a limit that is arbitrary and which you seem to be afraid is not enough -- I grant that physical limitations are a reality, but the thing about version control is that it's meant to be a comprehensive history of the project and if you have to stem that history for any artificial reason you run the risk of breaking the system. If you don't know exactly how much you'll need, a good rule of thumb is to choose the lesser of "as much as you can reasonably afford" or "twice what you'll think you need".
Imagine you've got a tree that will always grow as high as you can climb -- now imagine that you've asked your buddy to follow along on a ladder lopping off the lower branches with a chainsaw. Might this be a problem for you? Well, it depends how far you might need to back-track in order to climb higher when you find out that the last branch you were on is a dead-end, or worse yet, that you come to find out that the branch you *really* wanted was cut off prematurely, and low lies in the pile of discarded limbs at the base of the tree, presuming it hasn't yet been hauled off to the dump. This is what imposing arbitrary limitations on a version control system is like.
30GB might well be sufficient -- its certainly more than enough for any codebase, its just the art and sound assets that are worrisome, particularly because version control systems almost universally suck at binary files.
I would consider separating the code repository from the art repository -- perhaps even foregoing version control on the art assets (backups are necessary if you do this). Code history is of paramount importance -- art history is important, but its generally easier to be able to cherry-pick which art needs to be kept in the repo and which can be moved out. Its also worth noting that, if you split the code and art repos, that you may find that distributed version control (Git, Mercurial) works better for code, and centralized version control (SVN) works better for art.
Imagine you've got a tree that will always grow as high as you can climb -- now imagine that you've asked your buddy to follow along on a ladder lopping off the lower branches with a chainsaw. Might this be a problem for you? Well, it depends how far you might need to back-track in order to climb higher when you find out that the last branch you were on is a dead-end, or worse yet, that you come to find out that the branch you *really* wanted was cut off prematurely, and low lies in the pile of discarded limbs at the base of the tree, presuming it hasn't yet been hauled off to the dump. This is what imposing arbitrary limitations on a version control system is like.
30GB might well be sufficient -- its certainly more than enough for any codebase, its just the art and sound assets that are worrisome, particularly because version control systems almost universally suck at binary files.
I would consider separating the code repository from the art repository -- perhaps even foregoing version control on the art assets (backups are necessary if you do this). Code history is of paramount importance -- art history is important, but its generally easier to be able to cherry-pick which art needs to be kept in the repo and which can be moved out. Its also worth noting that, if you split the code and art repos, that you may find that distributed version control (Git, Mercurial) works better for code, and centralized version control (SVN) works better for art.
Author
BitBucket provides free private DVCS accounts, by the way.
Sorry for my delay in response. I've been doing more research on the issue and it seems that SVN stores changes using deltas, which reduce the amount of spaced needed for binary files, so my worrying about space seems to be negated by this if we can keep the raw asset files under decent control. (which shouldn't be more than 10-12-GB max),
Thank you all for your great suggestions.
I like the idea of both GitHub and BitBucket, but that's additional expense since we have 20+ users that we need to have committing to the repos. I've never delt with public repos, so I'm unsure if 'public' means they can be committed by anyone, or just people I assign... because it'd be catastrophic if a stranger made commits and we didn't realize when.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
