Please keep replies to the list so everyone can benefit.
On 3/27/06, Brian Krusic <brian@krusic.com> wrote:
> Thanks for the info, I'll just have to do the foreach loop.
>
> In terms of why, here is our story;
>
> We are doing CGI character development.
>
> The app we use; Houdini has whats called OTLs which are asset libraries
> allowing a character to act (jump, sit, etc...).
>
> There are global OTLs and show OTLs which are under a lot of flux (not my
> doing but thats how this place runs) and so I must introduce some form of
> anti-anarchy where I at east inform every one what version OTls work with
> what scene and there ocation (which PCs).
>
> Some versions of OTLs work for some indivuals (digital artist) scenes but
> can break other individuals scenes.
>
> These OTLs are C code which each artist must modify to there liking and in
> order to have the show work, must be distrod studio wide but they do not
> test there work for global compatibilty due to bad habits and tight dead
> lines.
Unfortunately, all the software in the world can't solve social
("people") problems. The users need to be broken of this habit. The
best way I can think of to achieve this is to enforce some unit
testing on the developer workstation (svn up, build/test, then commit
if tests pass - if *everyone* follows this, breakage should be found
much earlier) and then have a global integration testing environment.
Requiring regular updates and commits will be a major factor here.
Your deadlines will only get tighter if everyone isn't testing their
changes against everyone else's - things will break on a larger scale
and later in the dev cycle - a small bug fixed early is a bug fixed
cheaply. Wait too long and a small bug becomes a very large one, and
fixes don't come cheap then.
That, or each artist gets their own branch, and then you merge
everyone together on regular intervals into the trunk. But, as I said
before, you may have too long a lag before major breakage is found.
> I've never had to refine a pipeline of this nature so a first step to me
> would be gather info to develop a map or software topography of the studio
> so that we can proceed to understand the problem.
It sounds like you understand the problem pretty well - everyone is
working on their own version of the "base" system and not getting
their changes in sync regularly to get everyone caught up on everyone
else's changes.
If you haven't yet, give The Book (http://svnbook.org/) a read, as
well as /Pragmatic Version Control using Subversion/ (Mike Mason) and
William Nagel's /Subversion Version Control/ .
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 28 15:10:50 2006