2009/1/19 <postmaster_at_tigris.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
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1037140
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-01-20 09:28:09 CET