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.
Best,
-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 22:23:24 2004