I'm a rather recent subversion user, but I have been using CVS for
several years now. I have managed to setup, configure, and run
subversion (from the 1.0.6 source tarball), and I have read the
subversion book (yes, all of it), and the FAQ at tigris.org, though
perhaps not extra carefully.
My problem is that I cannot model in my head what exactly happens when
subversion commands are issued on a working copy that contains files
(or directories) taken from multiple repository revisions. This is not
an extraordinary case: this happens, I believe, in every working copy
just after a commit (or does it?). What puzzles me, for example, is
that when I commit some changes I have made to a file (say "tst.c") in
my working copy, and then issue a "log" at the working-copy toplevel
directory, I don't see the log-message from my latest commit: e.g
svn co svn://repsrv/test/trunk tst
svn commit -m "Changed tst.c"
** I don't see the "Changed tst.c" message **
I understand that this has something to do with the fact that the
working-dir toplevel is still from (or "at") the pre-commit revision,
and that if I do a "svn up", then the "problem" goes away. But I
cannot understand what *exactly* happens when I issue the "log"
command: The subversion book says about log:
The default target is the path of your current directory. If no
arguments are supplied, svn log shows the log messages for all
files and directories inside of (and including) the current
working directory of your working copy.
So if log shows "the log messages for all files and directories inside
... the current working directory", then isn't "tst.c" (the *HEAD
revision*, mind you!) inside my "current working directory", so
shouldn't the commit-message be shown? Or should the paragraph above
shows the log-messages of the commits affecting the files inside
the current working directory of your working copy, and applicable
to the revisions up to, and including, that of your current
or maybe again it should read:
shows the log-messages of the commits affecting the paths that
reside in the repository-subtree rooted at the URL corresponding to
your current working directory, and applicable to the all the
revisions up to and including that of your current directory.
All three, I believe, are *different*. I'm nor trying to start a
semantic bonanza here. All I'm saying is that if I have a working
copy, and even if I say:
svn status -u
and both of them print nothing, then I *still* have to to an "svn up",
in order to be sure that the command I give next will have the
expected results. To phrase it differently: If want to issue some svn
"query" (a "log", a "diff", a "merge", etc), then I first must do an
"svn status -u". If it prints nothing, then this means *not* that an
update isn't required (as someone would expect?), but instead that
"and update will probably be painless". So then you must do an "svn
up", and then issue whatever query you are about to issue.
Is there a more intuitive way to think of it?
Thanks in advance for your answers and comments.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Aug 1 21:03:33 2004