Hi, Well my experiences differs now that I've been using a lock based versioning system here for our 3D assets (scenes, textures, etc) for some time.
1) Locks on local files are a nuisance Often you'll need write access to some file even though you don't plan to reintegrate the modified file. Caches, shadow maps, etc. Sometimes you can't render / work without that. If the problematic file is just a reference of the scene you're actually editing, and you plan to only push the main scene back, it won't break anything, but if someone locked it then you're out of luck. People presented with this roadblock will usually just copy the local files to work. Then you're out of the versioning benefits. You actually created a "local, uncharted, unmaintained" branch, and situation is already the worst case scenario a versioning system can give you. Conclusion : I just keep chmod 777 -Ring the hell out of my local repository everytime I fail a test render because of a silly local lock. For me they are just an annoyance. 2) You can't always respect the exclusive rule. As much as people taking the lock on a file in turn is the theorically correct process, in practice it seems to me it often turned out as not doable. To be able to work in parallel you can set up as much as you can using the tools Maya offers, like references (one does uv editing in scene A, you reference scene A in scene B and shade there, etc...), still it has it's limits. At many points I found you had to work in parallel on same file, export and reintegrate, ie manually merge. If the versioning system doesn't allow that, then again people will just make a copy, and version that as a variant of the original scene. Back to the branch / merge case except again it's even worse as there is no information of what version and when this scene was branched from. Conclusion : I'd rather get a warning, and as a result of pushing the asset have a branch be created. That way I know I got to reintegrate the changes at some point, and the information of what it branched from is preserved. Merging can't be as efficient for Maya scenes than for code. Then again, a Maya scene is pretty much code though, typical production scene structure is often "load these refs, apply these commands" and in many cases you can extract diff patches that will help merging. Locks could be there, but as warning posts. Possibly make them "hard locks" for some people and "soft locks" for other depending on some accreditation level. Would love to hear thoughts of more as well ! Olivier Sebastian Thiel wrote: > >>But a locking mechanism tends to just be a substitute for good > communication.<< > I just have to pick this up quickly and state that ( human-based ) > communication cannot in fact not replace a ( server based ) locking > mechanism. During my everyday work it happens that I have to fix > scenes or adjust them. People would never ( and should not ) send me a > message everytime before they start working on a file just because I > could possibly anytime want to make changes. It's just not feasible, > even for people within one team. > Locking files based on human communication will suffer from a great > deal of human error as well, and will not be usable. > > > As long as you cannot diff the files you manage at all or at least not > in a meaningful way, exclusive write access to files is required. Even > with a perfect production management there are still guys like me that > at least want some notification if some other person is currently > registered to work on a file - without a server based system that > would not be possible. > > > But this is just my opinion based on everyday experience - others > might have made other experiences that they might want to share here. > > Regards, > Sebastian > > > -- Olivier Renouard --~--~---------~--~----~------------~-------~--~----~ Yours, Maya-Python Club Team. -~----------~----~----~----~------~----~------~--~---
