Revision control system for your demo sources?
category: general [glöplog]
yes, MULTIPLE TIMES REPEATEDLY!
Mercurial is a useless fucking piece of shit.
If someone else pushes a change to the repository ANYWHERE AT ALL IN THE FUCKING CODEBASE in the time it takes you to type your commit message, you have to piss about merging changesets manually and then do a second commit.
Fucking useless fucking cunty blast fucking software.
Just thought I'd share that.
If someone else pushes a change to the repository ANYWHERE AT ALL IN THE FUCKING CODEBASE in the time it takes you to type your commit message, you have to piss about merging changesets manually and then do a second commit.
Fucking useless fucking cunty blast fucking software.
Just thought I'd share that.
gasman has leading. We used Mercurial at work, but thankfully only as a stop-gap solution until our Subversion server has been set up.
Joghurt is a big mercurial fan...
I'm using git at work these days while pushing changes back to the company SVN-server. It works out really well in practice.
I really love a lot of the git concepts, like rebasing, amending, bisecting, stashing, squishing etc. There's a neat little tool for every common problem. And getting used to distributed VCS makes me never wanting to look back.
I'm sure a lot of this applies to mercurial and bazaar also, but I haven't really tried them enough to know.
Now, I'm considering switching to git for demo-coding as well. I mean, the very casual branching / pulling model fits demo-coding quite nicely! Just pull the code for the new part from the other coder, and make some branches for your new effects. Just merge it all when time comes for it. The only real let-down is that git-mingw doesn't come with git-svn these days.
I really love a lot of the git concepts, like rebasing, amending, bisecting, stashing, squishing etc. There's a neat little tool for every common problem. And getting used to distributed VCS makes me never wanting to look back.
I'm sure a lot of this applies to mercurial and bazaar also, but I haven't really tried them enough to know.
Now, I'm considering switching to git for demo-coding as well. I mean, the very casual branching / pulling model fits demo-coding quite nicely! Just pull the code for the new part from the other coder, and make some branches for your new effects. Just merge it all when time comes for it. The only real let-down is that git-mingw doesn't come with git-svn these days.
Quote:
I really love a lot of the git concepts, like rebasing, amending, bisecting, stashing, squishing etc. There's a neat little tool for every common problem. And getting used to distributed VCS makes me never wanting to look back.
same here. i'm using git now since 3 month at work and i've to say for code it's def the best vcs i've used so far. when there's some time i'll switch our demo stuff to git too as svn2git worked quite well at my company...
how does git handle 120gb 200k+ file projects?
http://www.telelogic.com/autodemo/synergy_auto_demo/index.cfm
I use bazaar for my personal stuff, coming from svn, it's very nice. I have no idea how it compares to git/hg/anything else.
plek: you're working on a demo made up of 120gb/200k+ source files? impressive! :)
plek: you're working on a demo made up of 120gb/200k+ source files? impressive! :)
no i was merely wondering how git would hold up for, lets say, a full scale game project.
i use p4 for everything. but thats at least partially habitual, so i'm interested in what else is around.
i use p4 for everything. but thats at least partially habitual, so i'm interested in what else is around.
niels: git is designed especially for large projects, making a new VCS for use with the linux kernel was it's main design-goal. I would assume it would work relatively well, but beware that you never make a partial check-out in git like you can do in some other VCS systems, you always have the full repo on your hard drive. This means that every developer needs to have room for all those 120gb files. There's also less available gui-tools etc for git, so it's probably not something your artists would want to work directly with... :)