[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Nick Patavalis <npat_at_efault.net>
Date: 2004-08-02 20:04:53 CEST

On Mon, Aug 02, 2004 at 10:10:44AM -0500, kfogel@collab.net wrote:
> Nick Patavalis <npat@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

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
  -- Linus Torvalds
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 2 20:05:17 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.