Now you have an initial repository to play with, so you can start to make changes.
The two workflows I'm going to describe here will vary slightly if you're working with one of the plugins for the supported IDEs (remember: Visual Studio, IntellIJ, Eclipse...) since they'll take care of the "check out / check in" cycle themselves.
IMPORTANT: Check-outs are not locks!
Before describing any workflow patterns, let me explain what a check-out is in Plastic.
A check-out in Plastic is NOT a "check out" in Subversion or CVS.
Let me make this very clear to avoid further confusion. When you do a "check out" in SVN or CVS, what you're doing is downloading code from the remote repository into your machine. This is a very different operation in Plastic. In fact, with Plastic (like in ClearCase, Perforce, SourceSafe and most of the commercial systems) the closest operation would be an update.
So, what is a check-out in Plastic? Check-out means: I'm going to modify this file.
- While I have a file checked out, does that mean no one else can check it out?
- No, it doesn't mean that, it just means: "Hey Plastic, I'm modifying this file, ok?"
- So does the server know about check-outs?
- No, not unless it is an exclusive check-out.
- Why do you guys even use check-outs at all??
- Well, with Plastic, you can avoid them entirely if you want. (I'll explain how later.) Some users, however, will prefer to tell Plastic they're working on something. Why? In a situation where you have a large codebase, it will unfortunately take Plastic a long time to automatically scan your entire workspace for changes. If you perform check-outs along with check-ins, then you're telling Plastic which files you've modified, so it doesn't take forever and a day to update. Also be aware that plugins like Visual Studio (compatible with SCC) do need to run the check-out cycle, but like I said, Plastic does this easily.