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, <bernie_at_fantasyfarm.com> 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!!!
>
> /Bernie\
>
> ------------------------------------------------------
>
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1035397
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_tortoisesvn.tigris.org].
>
Received on 2009-01-19 21:36:41 CET