Mark - sorry - again did not mean to say that it was the knee change that was a problem - I just noticed the same problem on the goose around the same timeframe as when that change was made - but I now just notice that David had also made the eyeblink changes to the goose very shortly after, around the same time.

The point is not in finding fault. I've noticed very definitely conflicts arising when changes have been made to the rig, or otherwise - while I am also doing decaling, texturing. One would think that these activities would not interfere with each other - but they seem to for some reason.

I have even had instances where I've updated - made my change & then tried to upload - and in that short time someone else has made a change to the model (or some other nonesense was going on) that produces a conflict. If I then do an update - it craps out my local model (granted it makes a .mine copy) - but I then still have to wait for Noel to resolve the conflict, before I can continue on with further changes.

The texturing is not usually an overnight process - it takes longer & is more iterative. Most times that I've done an update before I do a commit, regardless of how long I take (minutes versus days), and someone else has modified the model, I am left with a mess for my local copy. And then Noel has to resolve it. I prefer to minimize the number of times that I have to ask Noel to resolve a conflict. So I prefer to get it to a state that I feel is finished before trying to commit.

Our best bet is to try to coordinate with each other as best possible. We tried assigning tasks in the dotproject - no one looks at the dotproject (who can find it the task? anyhow). Posting a topic announcing texturing work doesn't seem to work either.

Too bad we don't have a sign-up sheet of sorts - at least we'd know if someone else was doing something before we started, and it might be easier to coordinate.

Unfortunately with so many people touching the same model - merging conflicts will continue to arise. And Noel or someone else will continue doing cleanup.

Since we are using decals, couldn't the texturer make blank decals and apply them? Then all that would have to be done is change out the blank decals with the painted decals when the texturing was finished. This would make it easy to take however long is needed to experiment while having quick, easy updates. Making the blanks would take up the most time between updates, but it could be done in sections. Would that work? Or is there a part of the equation that I'm not considering?

In some cases, and for some people that might work.

I bet there would still be conflicts when the images for the decals were changed to point to something other than the blank images, and someone else has changed something. Maybe not. Depends on what the changes were.

I would prefer to coordinate.

I have tended to play with types of mapping, different types and number of images per decal container, groupings, group properties. These groupings change sometimes with the imagery chosen. I find I go thru various decal setups to allow me flexibility to try things out - rather than just go with my first and only attempt.

The setup part for so-called "blank" images is the most time consuming & laborious part for me. Changing the images out is not the time consumer. Giving people choices, and then trying to consider their input is another time consumer. I could go with UGWUGWUGI * to cut that time down.

It has not been fun. I cringe everytime I have to commit a model. I sure don't want to do it more frequently,
as I sure don't want to keep having to resolve conflicts. That is the biggest time waster.

It hasn't ever taken me more than 2? weeks (not sure) to texture something. It usually takes another day to 1 week for the conflict to get resolved. That sometimes includes numerous emails back & forth with Noel & the other "changer", as well as time to then recheck the "resolved" model, and then possibly have to redo any work that couldn't be resolved.

To think of doing it more frequently - just makes it even more distasteful a process.

Sorry Fab - for hijacking this thread about your beautiful rooster - this really shouldn't be discussed here.

*UGWUGWUGI = u get what u get when u get it.

You're right about updating before modifying, and commiting as soon as you are done.

You're slightly wrong about "uploads without downloading first"
Svn forces this to happen if someone else commited what you modified since your last update.

model at rev 1
Sally updates
Thom updates
Sally modifies and commits rev 2
Thom modifies and trys to commit it will force him to update first. This merges his changes with rev2, if each changed different parts of the file all is ok.
The problems happen when Thom and Sally both modified the same section of the file, and Thom doesn't resolve the conflict correctly.

To reduce conflicts you should update what you are working on often and before making changes.
When you do make a change that is complete commit it. Committing often gives your self a back up, reduces the chances of a conflict, and makes so that it won't be you getting the conflict.

update is svn for download
commit is svn for upload
We should try to use these terms to match tortoise and svn's help so that we avoid confussion

If any one does get a conflict see the TWO wiki svn conflict page for how to procede.

Thanks

I moved the above posts here from the rooster topic

I fixed the rooster.

Didn't have anything to do with svn.
Fab changed the decals and some how the constraint targets got pointed to rooster2 instead of itself.
commited the fix.

Thanks

Thankyou Noel