[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: <kfogel_at_collab.net>
Date: 2004-08-02 20:49:52 CEST

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


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 2 22:23:24 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.