See comments inline
On Mon, Jan 19, 2009 at 2:39 PM, <postmaster_at_tigris.org> wrote:
> 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,
Just because you don't HAVE to have a Makefile, doesn't mean that you
can't. I use Makefiles to bundle Python apps. You could do the same thing
with Perl. Just a thought.
> 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?]
>
There is no 'right way' (globally), there's your 'right way', which is
whatever works for you. You can check in all changes at once (if you
want). I, and many others, perfer to check in changes in logical groups:
"fixed bug #1243", "added documentation for option foo", etc... TSVN makes
this particularly easy because the commit dialog lets you pick and choose
which files to 'check in'. In the CLI, you need to explicitly specify which
files to check in (or you get them all be default).
This, of course, means that you should only do one thing at a time in a
working copy before committing. The benifit is that it's easy to see what
you changed, AND (here's an important point) reverse it later.
For example: say you did these logical things: "fixed bug #12123", "added
documentation for 'foo'", "added feature X".
Scenario 1: You check ALL of them at the same time, no problem, until
later. Say you get all of these commited in revision 10 (r10). Later, you
discover that your fix to bug 12123 is wrong, or is causing more problems,
and you want to undo it. You'd have to manually undo the changes for that
and comit them. A better way: see next scenario.
Scenario 2: You "fix bug #12123" and check in (I'm using the CLI for
documentation perposes)
svn ci -m "Fixed by #12123"
...
Commited revision 10
Now, you add documentation for foo"...
svn ci -m "Added documentation for foo"
Commited revision 11
Now, you add your next feature:
svn ci -m "Added feature X"
Commited revision 12
Now, a while down the line (your at revision, say 20) and you want to undo
the change in revision 10:
svn merge -r10:9 .
That says apply a patch from revision 10 to revision 9 (i.e. the opposite of
what happened going from 9 to 10) to the current working copy (it's best if
it's a clean check out --- i.e. no modifications). Then, you can test and
and commit the change
svn ci -m "Undid 12123 bug fix in r10 (because..)"
ANYWAY, the crux is, if you break checkins up into meaningful chunks, it
makes the log more useful and (may) allow you to more easily undo things in
the future.
>
> 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 a difference in RCS and SVN: RCS works in individual files and had
not central repository.
When you commit changes, they are now in the repository. In order to get
those changes to other working copies, you must run "svn update" in them.
The keywords get expanded for files that have changed, but keep in mind: the
Revision is the LAST REVISION in which a given file was changed, NOT the
revision of the repository.
>
> 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.]
>
I was like that at first, but I got over it ;-). If you edit them, so
what? Just get in the habit of running "svn status" in that directory. If
something has been changed, use "svn diff" to see what. If you don't want
it, simply use "svn revert" to undo it.
>
> Thanks again. /b\
>
> ------------------------------------------------------
>
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1035847
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_tortoisesvn.tigris.org].
>
Your best best is to read the SVN docs again (and again). It's best if you
create a test repository and try things. When I was first learning SVN, I
created _many_ test repositories and tried things out. Even now, if I'm not
sure what a command will do, I'll create a test repository and try it.
Often, I'll just copy a working repository to a temp directory, create a
check out (of the temp repository), and try things out. If they work as
expected, I commit that change to the production repository.
The SVN manaul (and TSVN) have good explainations of how SVN does
revisions. It's a duplication of effort to put them all in this email.
- Kevin
Received on 2009-01-20 21:50:04 CET