Login | Register
My pages Projects Community openCollabNet

Discussions > users > Re: Re: Dumb newby question: moving from RCS

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

tortoisesvn
Discussion topic

Back to topic list

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

« Previous message in topic | 4 of 8 | Next message in topic »

Messages

Show all messages in topic

Dumb newby question: moving from RCS bernie at fantasyfarm dot com bernie at fantasyfarm dot com 2009-01-19 10:46:37 PST
     Re: Dumb newby question: moving from RCS "Kevin Grover" <kevin at kevingrover dot net> "Kevin Grover" <kevin at kevingrover dot net> 2009-01-19 12:36:28 PST
         RE: Re: Dumb newby question: moving from RCS postmaster at tigris dot org postmaster at tigris dot org 2009-01-19 14:39:59 PST
             Re: Re: Dumb newby question: moving from RCS jeanmarc Jean-Marc van Leerdam 2009-01-20 00:27:01 PST
             Re: Re: Dumb newby question: moving from RCS "Kevin Grover" <kevin at kevingrover dot net> "Kevin Grover" <kevin at kevingrover dot net> 2009-01-20 12:49:53 PST
             Re: Dumb newby question: moving from RCS Michael Dixon <michael dot dixon at denovosoftware dot com> Michael Dixon <michael dot dixon at denovosoftware dot com> 2009-01-20 14:44:50 PST
                 Re: Dumb newby question: moving from RCS "Kevin Grover" <kevin at kevingrover dot net> "Kevin Grover" <kevin at kevingrover dot net> 2009-01-20 16:14:20 PST
                     Re: Dumb newby question: moving from RCS Michael Dixon <michael dot dixon at denovosoftware dot com> Michael Dixon <michael dot dixon at denovosoftware dot com> 2009-01-20 17:04:55 PST
Messages per page: