I've been working in parallel with two other developers on creating sequence diagrams from use cases. What follows are merely some experiential observations, I'm by no means a UML subject matter expert! We're using IBM's Rational Software Architect (RSA), which is a mature tool, except for the fact that copying and pasting UML elements (in sequence diagrams, anyway) isn't trivial. IBM admits to a particular product defect with respect to this: http://www-1.ibm.com/support/docview.wss?rs=2044&context=SSCM72&dc=DB520&uid=swg21237757&loc=en_US&cs=UTF-8&lang=en&rss=ct2044rational. We're working on consolidating requirements, so a key idea behind our work is reuse of entities, boundaries and controls. These three things are classes in the standard Analysis Model which you can select once you create a UML project in RSA - it comes pretty close to imitating the MVC pattern. Entities are like models, controls are like controllers, and boundaries are like views. Recently we were able to set up a space for all of our models on a shared drive, but we're still waiting to be able to use a real repository that we can all work from. So, the situation has reinforced for me several points.

First, the necessity of standards and compliance to them. Of course there's UML 2.0 (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML), but how do you structure the files within the model (diagrams and UML elements) to make it easy to consolidate entities? I.e., do you put all entities in one directory, or keep them stored in a subdirectory which is a functional subsystem that they belong to? What about naming conventions for UML elements? When you come across a situation in a use case that seems to be beyond what UML 2.0 covers, do you try to find another specification, or come up with your own rules? Are people really going to buy into those rules, and who's going to manage them? I feel good about the team I'm working with on this, but if many more people join us, we'll have to really ensure that we're all following the same standards.

Second, generally speaking, it's very difficult to merge changes to a diagram, much more tricky than just merging source code, so it's worth looking at dividing the work up so that each diagram has only one author. That allows for a locking version control system: http://svnbook.red-bean.com/en/1.1/ch02s02.html#svn-ch-2-sect-2.2. Ideally, you would want to have one project that you're all working on and assign diagrams to individuals, but allow for entities, boundaries and controls

Third, it's great to be able to copy and paste elements between diagrams, but we've had no luck with this. Instead, one great tool that RSA offers is the ability to create sequence diagrams and import them into current diagrams. They're called 'interaction uses' and are pretty helpful in modularizing specific sequences. UML 2.0 now allows you to nest combined fragments, which is fantastic. Just remember that link that I noted above about being unable to move enclosed combined fragments!

Fourth, don't get TOO caught up in details and standards. It's easy to do. Of course you need to follow them, but plan on iterating through the diagrams you do, don't try to apply the waterfall method to this process. Go through the diagrams a few times if possible. Meet regularly with the others and discuss changes to the standards you've made. Do peer review of the diagrams.