Kevin, thanks very much for the explanation. I think you're right in that this is the crux of my problem:
... You'll probably discover that once you master the SVN workflow, you will no longer like the RCS workflow. They are fundamentally different: RCS works on files, SVN works on directory trees (including files and properties).
I [obviously] don't fully understand the SVN-style workflow and I've been through the TSVN docs and part of my problem is that it is trying to explain how SVN works in a complicated environment (with parallel changes and branching versions, etc) and I'm not seeing the simple-enviroment trees for the fancy-stuff forest.
The first few chapters of the svn book (svnbook.red-bean.com
) really explain the basics very well. The TSVN docs assume you know most of what is in the svn book.
With Perl apps, there's no "make" and "release" -- the checked-in ["committed"] files *ARE* the app, and so part of the workflow isn't clear to me: I have the hierarchy PROJECT. PROJECT/SVN is my repository and PROJECT/PROJECT is where the actual in-production app lives [together with its various "extra" files: logs, docs, config files, etc]. I can easily right-click on SVN, do "check out a copy" into PROJECT/NEWSTUFF, play around, and then do a "commit" on the whole directory [so everything I changed and tweaked would get "checked in" -- that's the right way to do an SVN-styule workflow, yes?]
Yes, and then you do an 'update' on the working copy in PROJECT/PROJECT to pull these changes into the production environment. In this setting, both PROJECT/PROJECT and PROJECT/NEWSTUFF would be working copies pointing to the /trunk of the repository.
When you embark on a major change, it is wise to create a branch from this trunk (say /branches/foo) and do a checkout of this branch into PROJECT/FOO. That allows you to continue to make small changes to the production via PROJECT/NEWSTUFF while working on the major change in parallel.
Everytime you commit something via PROJECT/NEWSTUFF, you should consider merging that change into your PROJECT/FOO branch. That way, re-integrating the major change later on becomes easier.
Anyway, this stuff is explained much better in the books and my experience with these matters is very limited, but hopefully this clears the fog a bit for you.
BUT: in the normal SVN workflow, how would that cycle propagate to producting a new "operational" version? [I'm guess that it would be in this last step [going from a commit in my NEW directory to "refreshing" the master copies in the PROJECT directory, however that happens] that the $REVISION$ and friends would get expanded, yes?
This is done by either merging changes into a stable testing/production branch or by creating tags (pure copies that will never be modified) and pointing the test/production environment to the new tag.
As a side note, I can get by without locking individual files, but I definitely would like to have the master PROJECT/PROJECT directory be read-only [so I don't forget and start editing *them* by mistake -- old habits die hard.]
You cannot lock a file in one place and not in another; a file is locked in the repository and can only be modified in the one and only working copy that was used to lock the file. All other working copies will have a read-only version of that file.