I know nobody will care, but I'm going to explain how the simple Dreamweaver source control process works, and how I made some decisions in designing my jEdit plugin.
The system requires to specify two root folders, a local one and a remote ("release") one.
When the user creates a new file locally, it's not uploaded until he decides to "check it in".
When the user chooses of working on a previously uploaded file marked as "checked in", DW operates the check-out of that file, i.e. the remote file is downloaded, overwrites the file in the same position (if it exists) and open it. More, a file with the same name plus the ".LCK" suffix is written aside the remote file, containing details of the user in the form "username||email"; this will block other people from checking-out the same file while he's working on it.
When the user is happy of changes, he operates the check-in; the file is overwritten on the remote dir and the LCK is removed. Until then, all the savings are operated locally, if not otherwise specified in the Preferences.
For very small teams, it works. There isn't any version control capability, or any diff tool, but it doesn't need any serious third-party product like CVS or ClearCase, it doesn't need to be correctly configured (I still remember how many days SourceSafe took to my previous project leader), and it doesn't need a server process to be running on the remote machine. The average Joe MacromediaUser will find it pretty cool.
But nobody's perfect, and even this little tool has its flaws.
Stupid thing number one: the remote file is marked read-only while checked out, BUT if a user really wants, the FTP PUT command (from inside DW!) will overwrite the file anyway. Understandably, this is one of the first FAQ you find on the support site... =8-O
Stupid thing number two: the PUT command is in the same menu as check-in/out, and also in the same toolbar; even worse, they are just one aside the other in the toolbar and one above the other in the menu. It's human to be wrong, but to continue is devilish. The only thing missing is a big red arrow with the sentence "Please ruin your daywork, use this interface" written on it.
Stupid thing number three: if you locally rename a checked-out file, and then check-in, a file with the new name will be uploaded, leaving the old one ghostly floating on the remote server with its LCK. It's then up to goodwill to clean the files, increasing the chances of something going wrong ("Ooops, I thought that file was useless, but it wasnt't").
Stupid thing number four: it's possible that you create a few new files locally, work on them for days, then, when trying to checking-in everyhting, you find that some file with the same name as one or more of yours already exists. You can just rename it, but what if that script is referenced by name (GET anyone?) from inside one of the other freshly uploaded scripts? You have to lose time playing with find & replace. Again, chances of screwing something increase.
I don't want to promote chaos in my plugin, thus I decided to eliminate these behaviours.
- A file won't be overwritten if not correctly checked-out by the user. If you are so sure you need to replace that file, take your responsabilities and do it manually.
- renamed files will be uploaded immediately, and will completely replace the old named ones. If you want to copy entire pages, feel free to use Ctl-A Ctl-C and then Ctl-V on a new buffer. I won't assume you're smart and organised, dear web developer, because I know I'm not.
- a file will be uploaded (and checked out) as soon as it's saved for the first time in the local directory. This won't eliminate the possibility of problems, but it should reduce the odds. Actually, this could be difficult to do with the current jEdit API, thus I'm still thinking about it.
- in other circumstances, check-in and out will always need to be explicitly requested. I.e., when a buffer is changed and saved, it won't be automatically uploaded. It would be dangerous and would make difficult to implement the "undo checkout" action.
- plugin version 2 (this summer?) could implement a simple version-control mechanism, just storing checkin dates & times.
Ok, enough playing, back to work :)
