next »

[Layl]

Working a bit with the plugin it's at least now bearable and doesn't quite get as much in my way.

[InfiniteStateMachine]

Glad to hear it. I completely forgot about the default to not allow you to check out. I've had a hotkey bound for so long it became muscle memory and when I use custom tooling or the unreal engine they handle that for you.

I must say I do like the one key opt in because I tend to sometimes organize code and line spacing as a nervous ADHD thing then realize that git picked up those changes when I didn't really mean to and I end up asking myself "what did I change in that file???" :D

[TheLastBanana]

I've never seen that happen before and I'm pretty sure the default behavior makes that impossible. Are your sure you arent' pushing with the -f parameter?

Somebody on the team may have used it, yeah. As I recall, we were having a lot of issues with people ending up on detached branches and pushing them to the server, then wondering why they couldn't pull in changes. Honestly, in retrospect it all sounds like things that could happen just as easily with Git. I should probably give Mercurial another chance now that I've worked with other SCMs.

Speaking of which, I've been working with a proprietary SCM lately. The GUI is clunky and crashes constantly on Ubuntu. I would use the command-line version, but there are several important features that are only in the GUI. Also, the command-line version regularly breaks itself and spits out meaningless JVM stack traces, with the only solution being to manually delete the program's cache directory. I've had to do this twice so far. It's making me want to stab my eyes out.

[ProgramGamer]

Wait, a program where the command line version is worse than the visual editor? That is bad.

[Dacke]

Not really. Getting lots of complex features into a GUI is really tricky. They often end up clunky and only able to handle certain tasks well. Which is why many command line programs are way more powerful and versatile than any GUI based program. Especially since you usually can use any programming language to script and combine them.

[TheLastBanana]

I think he was saying the opposite, Dacke -- the command line version is worse than the visual editor. It dies just as often, but with 3/4 of the features!

[Dacke]

I not read so very well 

[MorleyDev]

Personally I'd advocate considering using multiple source control solutions in a single project when working with large teams.

I would not recommend using git for source control over a lot of binary assets with artists and stuff, perforce and even svn handle those better and seem to be easier for artists to get their heads around. Best tool for best solution doesn't apply to the whole project, but the discrete sections of that project as well.

Git does work very well for code files. The git-flow workflow is a very nice workflow for developing a large project, and seems to fall down pretty hard in a lot of other SCM tools (Dear god trying to do things that way in SVN is pulling teeth).

The full build should be 100% automated anyway, so the programmers won't really need to care the artists are using SVN or Perforce or a network drive that gets backed up every weekend (okay, they might want to care about the last one. Don't do that one). Once you write the build scripts, it's all good. And really, having different repos vs a single repo won't complicate those too much anyway, regardless of the source control systems being employed.

Though with git, just learn the command line. The basic commands map more or less 1-1 for every other command line tool out there for source control. Command line good

[InfiniteStateMachine]

Wait, a program where the command line version is worse than the visual editor? That is bad.

Yeah that sounds crazy to me lol.

What is the name of this source control system?

Personally I'd advocate considering using multiple source control solutions in a single project when working with large teams.

Though with git, just learn the command line. The basic commands map more or less 1-1 for every other command line tool out there for source control. Command line good

Multiple source control solutions seems awesome but has been a new fresh kind of hell in practice in my experience There's too many situations where something is dependent across scm's and their order of submission messes up CI etc.  If there was better glue between solutions it might be mitigated to not be a problem but before going that route I'd take a look at he modern dual mode solutions rather than attempting to use glue. GitSwarm seems decent in theory but I'm not sure how well it would work in practice. I'd certainly give it a shot in the future though. The ideal of DCMS for code and a binary efficient solution in unison is certainly something I'd like to see happen in large game projects though. I'm looking forward to other people doing the work for me to improve the situation :D :D :D

I agree about the command line regarding git. I usually am not an overly giant advocate of command line stuff but git in particular seems to function best without a gui. Except timeline views obviously but that's one of the places git falls short.

I should add I haven't tried smartgit. I've been told it's much better than the other solutions but after using about 5 git gui's and not really liking any of them I've decided the command line is my home for git.


EDIT : The more I think about this the more I want to attempt to write a decent glue layer as a hobby project.  That main problem is it's hard to simulate scale for testing purposes.

[MorleyDev]

When you say it caused problems, were you trying to treat it as a 'repository of repositories' approach, so there was still a single parent repository? Because I was thinking more along the lines of completely breaking the connections.

Treat code, scripts and assets as separate projects entirely with their own CI workflow, and then have a single 'full build' join point at the end which kicks out the final package. There's a level of complexity needed to justify that, of course. Code and scripts need a level of independence, and assets need to be able to just "get latest versions and drop these in" to work. But if you can get the workflow down and get the team communication required down, there's potentially a lot of power in that separation.

[InfiniteStateMachine]

When you say it caused problems, were you trying to treat it as a 'repository of repositories' approach, so there was still a single parent repository? Because I was thinking more along the lines of completely breaking the connections.

Treat code, scripts and assets as separate projects entirely with their own CI workflow, and then have a single 'full build' join point at the end which kicks out the final package. There's a level of complexity needed to justify that, of course. Code and scripts need a level of independence, and assets need to be able to just "get latest versions and drop these in" to work. But if you can get the workflow down and get the team communication required down, there's potentially a lot of power in that separation.

There's no single parent repository in most of the multi-CMS projects I use although I have worked on projects before where there's a single repo and it feels a bit like "distributed grafted onto a centralized model". Both ways have had their respective issues.

The de-linking of assets to particular code builds is one of the contributors to having CI spit out broken builds. Merely pulling in the current asset state at the time of building sounds plausible in theory but rarely works 100% of the time in practice. Pipeline changes, asset dependent code changes (I know this is ripe for criticism but this is another case of the idealism vs pragmatism) and changes to code that involves asset schema changes are just a few of the reasons you don't want to completely decouple different aspects of your project entirely. Once you start introducing a sandboxed language intended for use by artists and designers which can become invalidated by schema or code changes things get even more nuts.

I don't doubt that in theory what you are suggesting is ultimately the way to go but the current state of these types of systems is just not there yet. There's enough dissatisfaction with current solutions to justify expensive projects like Plastic, Swarm etc. Because of this I believe we should see some awesome solutions in the near future. We're close but we're in a awkward phase right now while things are still being figured out. The pieces are all there, they just need to be combined better.

btw if anyone knows of any active projects that try to solve the specific issues of large content heavy repositories where programmers are not the sole users please let me know. This is an interesting problem and I'm always super interested to see how others have approached the issue.

I've sat down a few times and tried to design out a content management system that would treat something like git as a first class system. While I think I have some ideas that could help improve the situation, the reality is that it would be relatively quick to get a proof of concept but a crazy amount of work to get something that would be compatible for all disciplines (api support for tooling, CI version lockdown stuff etc..).

 
ps : morley check your pms :p

[MorleyDev]

Ah yes, I can see how those situations can cause problems. I can think of process workarounds, using a promotion system to tag ready-for-use assets and mark breaking changes and such, only taking tagged builds to the full build (or only considering it problematic when tags that say they should work together don't).

npm-style dependency resolution could be used to solve versioning, major.minor.patch and all that. Break something, shift minor. Don't, shift patch. Hmm...There's still always room for a few more Jenkins plugins to make it easier

Yeah, this is definitely something I could lose a lot of spare time writing glue stuff for. I've used similar systems in non-video game environments in the enterprise and it's worked, but the extra-tight coupling and extra-bespoke situations you can get in games compared to everything else does make for more...fun. ^^

Though saying that, the pieces are there after all. If it became a solved problem, oh the fun we could all have. It's very similar to other recently solved problems after all. We've made leaps in database version management already, it's the same fundamental problem in a lot of ways...

[InfiniteStateMachine]

Most definitely. This is not exactly something I'd call a "general use case".

This thread has me charged now. I"m fighting the urge to attempt to write a glue layer :D

[Cheesegrater]

btw if anyone knows of any active projects that try to solve the specific issues of large content heavy repositories where programmers are not the sole users please let me know. This is an interesting problem and I'm always super interested to see how others have approached the issue.

I know some people who are having good results with git-annex.

[InfiniteStateMachine]

Thanks for the info. Reading the docs now.

[Joeb Rogers]

I've gotta say, I love GitHub. I haven't yet had reason to rollback any of my work (I'm pretty careful), but I love the feeling of safety knowing my hard work is backed up and able to be accessed in any version from the first file to the finished product.

I don't know how many of you know about this, but GitHub also recently (relatively) released a desktop application. Unlike before where you'd be typing command prompts and the like, it's completely visual and user friendly. You can create new repos and it will automatically track and notify you when there are uncommitted changes within the repo's folder. Just as intuitive (as far as my experience goes) as manually typing all the git, but a lot easier to use and faster as well.