CG management softwares and issues

[angus_davidson]

Thats pretty interesting. Worth checking out thanks ;)

[csaez]

now if we could just get check in, check out, and history built into Soft ;) wheee

Version control is not a softimage-only thing, you will need it in almost every file generated through the pipeline.
I'm not sure that's the right approach.

[angus_davidson]

In theory you should be be able to regenerate everything from your base scene file. Its not 100% solution, but it would be a big step up from what we have now.

[csaez]

In theory you should be be able to regenerate everything from your base scene file. Its not 100% solution, but it would be a big step up from what we have now.

I think you're missing the big picture here, a production environment involves a lot more than '3D content'. That's why all commercial/in-house solutions tend to work as standalone application + some integration plugins, its a generic problem and should be solved at a generic level IMO.

[angus_davidson]

I think you're missing the big picture here, a production environment involves a lot more than '3D content'. That's why all commercial/in-house solutions tend to work as standalone application + some integration plugins, its a generic problem and should be solved at a generic level IMO.

I think you miss understood what I was saying. I wasnt saying that soft was the only thing that needed source control. I was also not looking at production enviroments (where pretty much everything will be sorted out by a TD that knows what is required).

I was saying for those folks who are not part of a large pipeline it would be nice to have the option of something simple that they could easily be implement not to have 55 renamed copies of a file. A simple thing like an xsiaddon that allows you to seamless integrate with SVN would be great. For those people who are part of a big setup they will more then likely need to use something far more robust which obviously is generic enough to handle whatever applications their pipeline requires.

[csaez]

Fair enough

Take a look at mercurial/tortoiseHg too, I've been using it for a long time and I think it's better suited for what you're describing than SVN (distributed architecture, faster, etc).

[angus_davidson]

Will do ;)

[gustavoeb]

Hi Cesar, I was looking at your posts on this thread, and as I like this workflow topic Ive decided to look it up in a bit more depth. So I have read a bit about Git, Mercurial and Subversion.
From this initial reading I could gather that the first two (git and mercurial) are distributed, some of the people i read treat this as the being the future.
The main thing in both of them is that they look very much targeted to code dev. Even though Trovaldis say git is more of a file system. Anyhow two limitations I see are:
1. All files in the repository must be local. You can have subrepositories, but seems a bit more clunky and not all feats are suported (so says mercurial documentation)
2. Looks like this tools are targeted mainly to deal with text files instead of binaries. Even though some CG software output ASCII files i wouldnt say it is safe for a versioning program to just merge things together.

Here is some considerations I found about Mercurial and binaries http://kiln.stackexchange.com/questions ... -mercurial

That said Subversion treats every file like a binary, unless you tell it otherwise. It also allows for pulling and pushing of specific folders (no need to have the whole project in every machine).

To be honest I can only imagine what are the implications of such designs when using such tools for versioning vfx files. As most places I work were small and did versioning manually or through little scripts... would you care to share some thoughts on this?

Cheers

[csaez]

Hey Gustavo,

I'm not a 'pipeline guy' and I can be wrong but the main thing with SVN-like systems is you will not end up using version control on a daily basis at all, probably will use it in the publication stage but you'll still need those '55 renamed copies' outside the system. With mercurial it's not a problem and you can take advantage of version control at a user level.
About binary files, well, we can't merge changes so easily as with text files, so the standard way to deal with it is locking files on the server to avoid concurrences, you can download a file at any time (read-only) but if you wanna work on it you should download->lock->work->unlock->upload->done.
On the workflow side of things (pulling and pushing of specific folders) you can always split up the project into different repositories that make sense for you, it's more about a personal preference rather than a system's limitation.

This article does a good job explaining the key diferences between SVN and mercurial.

Again, I'm not a 'pipeline guy' and I can be wrong, I'm quite sure you can find a lot more info from experienced people on the mailing list

Cheers!

[sonictk]

SVN is gold, esp. since it has imaging diff functions as well built-in now. And it doesn't always treat all files as binary; the first 1024 bytes are looked at to determine its binary status. It works pretty well with PSDs and other files that can be saved as ASCII (Maya scenes, XSI scenes too, etc.) ZBrush ZTLs are among those that don't really work well with SVN though.