Behavior of "log" when WC has nodes from multiple revs.

[Nick Patavalis <np...@efault.net>]

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
    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:

    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.

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
    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.
/npat

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Behavior of "log" when WC has nodes from multiple revs.

[kf...@collab.net]

Nick Patavalis <np...@efault.net> writes:
> No I'm not talking about this difference. My two rewrites are, I
> believe, different in a much more fundamental way: What happens if
> inside my working copy I have a *switched* subdirectory? The first
> rewrite indicates that I will see logged messages affecting the
> switched paths. The second indicates that I will not. Which of the two
> is true?

I believe you will not see logs for the switched paths.

In other words, running "svn log" in a working copy is exactly the
same as running

   $ svn log -rBASE URL

where BASE is the revision of ".", and URL is the url for "." as
returned by "svn info".

> I agree that the default behavior must *not* be changed until the next
> major release. Until then, a switch that enables the more "intuitive"
> semantics could be provided (but this is also arguable). Personally I
> would settle for a manual update that describes exactly what happens.

Hmmm, would you care to write the patch?

(Not sarcasm, it's actually the most efficient way for the change to
get done.)

> You 're right, that wasn't clear at all. What I mean is this. I'm in a
> working directory. I plan to do something like:
> 
>   svn del dir1
>   svn commit 
> 
> Before doing this I do "svn status" and it shows nothing, then I do
> "svn status -u" and also shows nothing. Is is ok to delete and commit,
> or do I have to do an update first? When a novice user (yes, more
> novice than myself, this _is_ possible) comes asking why the heck the
> commit failed while "status -u" showed no nodes needing update, then I
> have to tell him something along the lines: "Well, look, before doing
> a commit, even if status and status-u show nothing, do an update. Just
> in case". This "just in case" is what I don't like.

Oh, that has nothing to do with the log situation.  It's a totally
separate non-intuitive behavior :-).  I think when you remove a
subdir, either it or its parent (or possibly both) must be at HEAD
when you commit.  I'm not totally sure about that, just an offhand
memory.  Try experimenting?

> Oh, another issue (maybe I should have posted it on a different
> message, but anyway). I do:
> 
>    svn diff --notice-ancestry \
>             --old svn://host/rep/proj/branches/b1/dir1 \
>             --new svn://host/rep/proj/trunk/dir1
> 
> And I see a file in "dir1" getting deleted and added-back again with
> exactly the same contents. This what I expected to see. Then I do:
> 
>    svn diff --notice-ancestry \
>             --old svn://host/rep/branches/b1/dir1 \
>             --new ./dir1
> 
> Where "dir1" is a fully up-to-date working copy, and I see no
> differences. It seems as if "--notice-ancestry" was ignored in the
> latter invocation. Is this reasonable, or am I doing something wrong?

I'm not expert enough in these to help, but you might want to post
again with a subject line that indicates you have a question about
--notice-ancestry.  There are people on this list who might be able to
help, if they see the message.

Best,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Behavior of "log" when WC has nodes from multiple revs.

[Nick Patavalis <np...@efault.net>]

On Mon, Aug 02, 2004 at 10:10:44AM -0500, kfogel@collab.net wrote:
> Nick Patavalis <np...@efault.net> writes:
> > 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.
> 
> 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 [...] If that's the
> difference you're thinking of, then yes, your second rewrite is the
> most accurate.

No I'm not talking about this difference. My two rewrites are, I
believe, different in a much more fundamental way: What happens if
inside my working copy I have a *switched* subdirectory? The first
rewrite indicates that I will see logged messages affecting the
switched paths. The second indicates that I will not. Which of the two
is true?

> 
> 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.
> 

I agree that the default behavior must *not* be changed until the next
major release. Until then, a switch that enables the more "intuitive"
semantics could be provided (but this is also arguable). Personally I
would settle for a manual update that describes exactly what happens.

>
> 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.
>

You 're right, that wasn't clear at all. What I mean is this. I'm in a
working directory. I plan to do something like:

  svn del dir1
  svn commit 

Before doing this I do "svn status" and it shows nothing, then I do
"svn status -u" and also shows nothing. Is is ok to delete and commit,
or do I have to do an update first? When a novice user (yes, more
novice than myself, this _is_ possible) comes asking why the heck the
commit failed while "status -u" showed no nodes needing update, then I
have to tell him something along the lines: "Well, look, before doing
a commit, even if status and status-u show nothing, do an update. Just
in case". This "just in case" is what I don't like.

Oh, another issue (maybe I should have posted it on a different
message, but anyway). I do:

   svn diff --notice-ancestry \
            --old svn://host/rep/proj/branches/b1/dir1 \
            --new svn://host/rep/proj/trunk/dir1

And I see a file in "dir1" getting deleted and added-back again with
exactly the same contents. This what I expected to see. Then I do:

   svn diff --notice-ancestry \
            --old svn://host/rep/branches/b1/dir1 \
            --new ./dir1

Where "dir1" is a fully up-to-date working copy, and I see no
differences. It seems as if "--notice-ancestry" was ignored in the
latter invocation. Is this reasonable, or am I doing something wrong?

Thanks for your reply
/npat

-- 
Hey, maybe I could apply for a saint-hood from the Pope.  Does
somebody know what his email-address is? I'm so nice it makes you
puke.
  -- Linus Torvalds

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Behavior of "log" when WC has nodes from multiple revs.

[kf...@collab.net]

Nick Patavalis <np...@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