Nick Patavalis <npat@efault.net> writes:
> 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?).
You are correct, that's what happens.
> 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
> cd tst
> vi tst.c
> svn commit -m "Changed tst.c"
> svn log
> ** 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:
Again, correct.
> 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
> read as:
>
> 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
> directory.
>
> 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.
Both your rewrites are accurate, yes.
In other words, svn takes the revision of "." and gets the log
messages up to and including that revision. Some files/dirs
underneath "." may be at higher revisions, but those higher revisions
won't be included (until you update "." to at be least that high
itself, or you invoke svn directly on one of those other targets).
> All three, I believe, are *different*. I'm nor trying to start a
They're not different, I think. The first one doesn't talk about
revision numbers at all, just about paths. It doesn't contradict the
second two, it merely fails to say something important, something that
your rewrites *do* say.
Your rewrites both talk about the revision number behavior. Maybe the
way in which they are different is that the your second rewrite makes
it clear that the recursion is deep -- that the log messages for all
files and subdirs are fetched, not just those that reside directly
inside the implied "." target. If that's the difference you're
thinking of, then yes, your second rewrite is the most accurate.
> semantic bonanza here. All I'm saying is that if I have a working
> copy, and even if I say:
>
> svn status
> 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.
Right. Well, almost right -- you don't *have* to do an "svn up". You
could instead run "svn log URL" (where you get the URL from running
"svn info", for example). When you use a URL target, Subversion
doesn't pay any attention to the working copy, and therefore uses the
head revision in the repository instead of the working copy base
revision.
By the way, I completely agree with you that the current behavior is
counterintuitive -- it still bites me from time to time. I believe it
should be changed; however, it's not clear that we should do so before
2.0, due to constraints on interface/behavior changes in the 1.x
series.
> 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?
Whups -- sorry, I'm not really sure what you meant by "required" and
"painless", or exactly what you were getting at in in general that
last paragraph.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 2 18:44:08 2004