Login | Register
My pages Projects Community openCollabNet

Discussions > users > Dumb newby question: moving from RCS

Project highlights: :. Download .: :. Support .: :. FAQ .: :. Translations .: :. Donate .: :. Report Bug .:

tortoisesvn
Discussion topic

Hide all messages in topic

All messages in topic

Re: Dumb newby question: moving from RCS

Author Michael Dixon <michael dot dixon at denovosoftware dot com>
Full name Michael Dixon <michael dot dixon at denovosoftware dot com>
Date 2009-01-20 17:04:55 PST
Message Kevin Grover wrote:
> He could have created a repo in PROJECT\SVN and access it via the
> file:// protocol.
Ah right, of course. I tend to forget about file://, but yeah, that
makes a lot more sense.

-Mike

Re: Dumb newby question: moving from RCS

Author "Kevin Grover" <kevin at kevingrover dot net>
Full name "Kevin Grover" <kevin at kevingrover dot net>
Date 2009-01-20 16:14:20 PST
Message
Attachments

Re: Dumb newby question: moving from RCS

Author Michael Dixon <michael dot dixon at denovosoftware dot com>
Full name Michael Dixon <michael dot dixon at denovosoftware dot com>
Date 2009-01-20 14:44:50 PST
Message postmaster at tigris dot org wrote:
> 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?]
>
Just to clarify, because from your wording I can't tell whether you're
clear on the concept: Subversion is a client/server application. The
master copy of your repository doesn't live in PROJECT/SVN; it lives on
the server. (The server may of course be running on the same machine as
you run the client and do your work, but the server is logically
separate from your working area.)

Other than that, yes, the workflow is correct. Rightclick a folder and
then check out a working copy *from the server* to PROJECT/NEWSTUFF,
make your changes, and then commit to send your changes to the server.

When you're ready to make your changes live, copy the files from an
updated working copy to your production folder (PROJECT/PROJECT).

btw, you probably want to keep your docs and config files versioned too.

-Mike

Re: Re: Dumb newby question: moving from RCS

Author "Kevin Grover" <kevin at kevingrover dot net>
Full name "Kevin Grover" <kevin at kevingrover dot net>
Date 2009-01-20 12:49:53 PST
Message
Attachments

Re: Re: Dumb newby question: moving from RCS

Author jeanmarc
Full name Jean-Marc van Leerdam
Date 2009-01-20 00:27:01 PST
Message 2009/1/19 <postmaster at tigris dot org>

> 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.


--
Regards,

Jean-Marc
--
      ___
 @@ // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
  \ \_/_\_/> The coolest Interface to (Sub)Version Control
  /_/ \_\ http://tortoisesvn.net
Attachments

RE: Re: Dumb newby question: moving from RCS

Author postmaster at tigris dot org
Full name postmaster at tigris dot org
Date 2009-01-19 14:39:59 PST
Message 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.

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?]

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?

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.]

Thanks again. /b\

Re: Dumb newby question: moving from RCS

Author "Kevin Grover" <kevin at kevingrover dot net>
Full name "Kevin Grover" <kevin at kevingrover dot net>
Date 2009-01-19 12:36:28 PST
Message
Attachments

Dumb newby question: moving from RCS

Author bernie at fantasyfarm dot com
Full name bernie at fantasyfarm dot com
Date 2009-01-19 10:46:37 PST
Message 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.

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.

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.

Thanks for your patience!!!

  /Bernie\
Messages per page: