Code:
When you read the title of my question, you probably thought I was stupid. Or still do. Regardless, I'm curious how you can work on a project and have multiple people manipulating files, and making changes? Understand, I've never worked on a game outside of BYOND, so I'm not entirely sure how game development works outside of it. I know when I'm coding, I love to compile and run when I make changes, actively tinkering with what I changed. Is there anything you folks use, like Dropbox?
ID:1801598
 Mar 5 2015, 12:55 pm
|
|
|
Mar 5 2015, 12:57 pm
|
|
Ganite
 |
Dropbox but not good for you if you have multiple programmers.
|
Multiple programmers is bad? Shoot. There are some HUGE projects on BYOND, I'd be surprised if none of them used multiple programmers.
| |
Well I didn't mean it was bad I ment using dropbox with multiple programmers is bad. Since it can corrupt and mess up files if your all in the source at the same time.
| |
Look up SVN. If you are working with multiple programmers, SVN is the only way to go.
| |
Git, SVN, CVS, Mercurial, TFS... They are all roughly the same thing. The differences between them are minor and they all have unique advantages and disadvantages.
RCSes are all vying for dominance right now, and SVN and git are just two of the major players at the moment. | |
Anything that supports versioning, branching, and merging with multiple people checking in code is helpful. I'm most inclined to use TFS (for some peculiar reason), but Git is a reasonable alternative.
Both also possess bug/task tracking features, which is great if you are the type of person who likes to have that sort of information at your fingertips. | |
Git is an option, I much prefer SVN though. Merely because I have more experience with it. Call me biased.
| |
+1 SVN
Git is fine though, you'll find more free SVN hosts if you can't setup your own. | |
One thing I never really understood about Git was the concept of offline repositories. To me, RCS is an online service. It just seems outside of the scope of the entire concept to allow offline pushes.
I'll admit, Git is nice, though. | |
Well, it's more-so that git affords you local branches, which is a /massive/ boon when dealing with experimental or refactoring work, particularly in larger projects.
The problem goes like so: Developer X is tasked with refactoring some element of the project, while 4 other developers continue more regular feature development on the existing master codebase. In SVN, you'd probably play it like this: Create refactoring branch for X. 4 other devs continue to commit to trunk. X finishes refactoring on branch, but is now 20 commits behind trunk. X performs merge of refactoring into trunk. X cries, resolves conflicts, and probably asks the other 4 devs to stop working entirely while he/she tries to resolve conflicts. 4 devs carry on anyway, X finds yet more conflicts by having to re-merge, cries some more, then eventually merges. In Git, you'd probably play it like so: X created local refactoring branch. 4 other devs continue to commit to remote master. X periodically (like, could be as frequently as every hour) rebases refactoring onto remote master. The delta is quite small, conflict are as such small and manageable, and git auto-resolves many conflicts. X finishes refactoring on branch, is perhaps 1 or 2 commits behind remote master, possibly even none. X updates local master to remote master, merges refactoring to local master (probably with no conflicts), pushes to remote master. Much of the power of git (and local branches facilitate this) is from the doctrine that merging is cheap, and the deltas between branches are kept small enough that git can auto-resolve intelligently, and so you avoid merge hell. You /can/ kind of try a similar methodology with SVN, but you have a great deal more round trips, which breaks up your workflow, and SVN generally doesn't track things like file renames or file fudges as well as Git, offering you more scope for conflicts. And the bigger the team you get (or the bigger the codebase) the more SVN's design starts to give you productivity issues there. | |
My branches on the numerous projects I've committed to always wind up in the double-digits behind the head revision, because I do a lot of refactoring. Plus, there's always the big debate about my methodology because I like to think about how we would use something in the future rather than how we're currently using it when I design stuff.
I definitely understand merge hell, and while git makes it a little easier, I don't think revision merging is ever going to be something that's made painless. | |
No, true, but git does make it considerably less painful in my opinion. Local branches also tend well to "lets try this out ..." stuff, which you then basically stash and come back to, if more important work trumps your play work.
| |
I like git quite a bit. Github is also nice.
| |