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
/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
Received on Mon Aug 2 20:05:17 2004