See comments inline.  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).

On Mon, Jan 19, 2009 at 10:46 AM, <> wrote:
I'm transitioning from decades of using RCS to TortoiseSVN and I'm having a hard time getting my head around it all...  The main problem is that I need a *lot* less than SVN wants to do, and I'm trying to figure out how to make SVN do _little_ enough to meet my [minimal] needs.

Note, too, that virtually everything I'm doing is in Perl, and so I don't bother with makefiles, and I don't need to make "executables" that are compiled into some other directory eventually to produce executables.  Where the "source code" lives is where I do my work, directly.

Also, there's "just me", so no need for merges or parallel development or any of that kind of stuff.  What I've always done in the past is created a directory to hold all of the files associated with a project, made an "RCS" directory in there and everything to do with the project is all nice and tidy and in one place [I do most everything in Perl, so the .pl's, the doc files, config files, even the data files [e.g., using sqlite] are all in one place].  Since the version stuff in RCS is manual, and by file, I have control over which of the files in the project directory are locked/checkedin/revisioned and which are/canbe just ignored.

And so my dumb questions:

1) can I put the repository for a project *IN* the project directory [ala './RCS'?].  I can deal with having an extraneous level of directories if necessary [e.g., PROJECT then PROJECT/SVN and PROJECT/PROJECT, if I have to], but it'd be nice not to.

No.  The Repository is, and must be, a separate directory tree.  It's managed by SVN and, normally, not even visible to the user(s).  Most (all?) of the distributed version controll systems (Mercurial, git, monotone, arch...) put the entire repository in the source dir.  Perhap's they would fit your use-case better?  However, if you're having trouble wrapping your head around SVN, the DVCS (Distributed Version Control Systems) may be even more trouble.

2) Can SVN work in "lock" mode, as RCS did?  I really don't want to make parallel hierarchies and copy things over when I want to work on something [especially since there'll be a bunch of other files in the project directory *NOT* being revisions [config, data, notes, etc] and I'd need most of those copied to get a working "paralleL' development directory -- I'm quite confortable going into the "master" directory, "locking" one of the source files, working away in place, then doing a "ci -u" when I'm done, so the 'master' directory always has read-only copies of the stable stuff and might have a writeable copy of a file or two I was working on and may have another bunch of  read-only or read-write files that shouldn't be of any concern to SVN.

Yes.  You must set a property (svn:needs-lock, I think) on each file you want to be locked.  Normally, this is only needed for binary files becase SVN can merge changes from different users.  But, since you're the only user, you should never really _need_ locks.  See the next section on more about properties.

3) I'd like something like "$ID: $" -- I saw something in the docs [like on page 130..:o)] about svn:keywords but I didn't quite understand what I'd need to do... surely it must be easy to have a program know its own version?  [I realize this is different in the SVN world: in my [old] world, *files* had revisions and it was easy for RCS to update the magic keywords as it checked out the file, and now *projects* do... and that's fine, but still I'd like to be able to put the version # into the 'herald' when the pgm starts up, etc.  I guess the tricky part with SVN is that if I use the version # in file A and I edit and "commit" file B, *something* would have to know to go back, as part of the commit, to "fix" file A to have the project revion # updated.

Yes, SVN has $Id$, $Revision$, $URL$ (like CVS $Source$) and some others.  HOWEVER, SVN does not expand them by default.  You must ask for them to be exapnded, one each file, by listing them in the svn:keywords property for those files.  (This prevents accidental corruption of binary files).

You can set up automatic properites so that newley added files (matching patterns) will get properties you want.

Keep in mind, where RCS versions the contents of individual files, SVN versions the contents (and properties) of files and directories TOGETHER.  Properties are any arbitrary pieces of information or control data associated with a file or directory.  You can make them up to suite your own needs.  Properties with a prefix of 'svn:' are reserved for use by SVN (you should never use the 'svn:' prefix for your own custom properties - they will work, but it's poor form).  Most have special meaning and affect the behavior of SVN.  For example, setting 'svn:eol-style' to 'native' causes files be be checkouted in the natvie EOL style (LF on UNIX, CR-LF on Windows, etc...).

Read the SVN (and TSVN) Manuals a couple of times.  A thing to keep in mind: SVN is the version control system.  It's a library that TSVN (a Windows client) uses.  You can use any SVN client.

SVN, since it versions trees, makes it easy to know what groups of files belong together at what revisions: something that you must do manually with RCS.

Thanks for your patience!!!



To unsubscribe from this discussion, e-mail: [].