svn log behaviour

3 views
Skip to first unread message

Alex Bligh

unread,
Feb 12, 2011, 12:03:45 PM2/12/11
to us...@subversion.apache.org, Alex Bligh
If I do "svn log ." in a directory, it does not list all changes made to all
files in that directory (as shown up "svn log <filename>"). I've pasted an
example at:
http://pastebin.com/SFYDtkBk
where r12062 does not show up in "svn log .", but does on the changed file.

svn diff . does the expected, and the file is not in svn:ignore.

Is this deliberate and how do I get a recursive list of logs?

--
Alex Bligh

Ryan Schmidt

unread,
Feb 14, 2011, 2:10:08 AM2/14/11
to Alex Bligh, us...@subversion.apache.org

Is the directory up to date? Try "svn up" first. Otherwise you'll only get logs up to the revision of the directory (shown with "svn info").

Alex Bligh

unread,
Feb 14, 2011, 2:57:50 AM2/14/11
to Ryan Schmidt, us...@subversion.apache.org, Alex Bligh

--On 14 February 2011 01:10:08 -0600 Ryan Schmidt
<subversi...@ryandesign.com> wrote:

Yes, the directory is up to date. In fact all changes were made in that
directory (not on another machine).

--
Alex Bligh

Ryan Schmidt

unread,
Feb 14, 2011, 2:59:34 AM2/14/11
to Alex Bligh, us...@subversion.apache.org

On Feb 14, 2011, at 01:57, Alex Bligh wrote:

> On 14 February 2011 01:10:08 -0600 Ryan Schmidt wrote:
>
>>> If I do "svn log ." in a directory, it does not list all changes made to
>>> all files in that directory (as shown up "svn log <filename>"). I've
>>> pasted an example at:
>>> http://pastebin.com/SFYDtkBk
>>> where r12062 does not show up in "svn log .", but does on the changed
>>> file.
>>>
>>> svn diff . does the expected, and the file is not in svn:ignore.
>>>
>>> Is this deliberate and how do I get a recursive list of logs?
>>
>> Is the directory up to date? Try "svn up" first. Otherwise you'll only
>> get logs up to the revision of the directory (shown with "svn info").
>
> Yes, the directory is up to date. In fact all changes were made in that
> directory (not on another machine).

Just because you committed the changes from that directory does not mean it is up to date. In fact, usually, after committing changes, your working copy has mixed revisions and is therefore not up to date. Please verify whether running "svn up" first fixes the problem.


Alex Bligh

unread,
Feb 14, 2011, 3:09:08 AM2/14/11
to Ryan Schmidt, us...@subversion.apache.org, Alex Bligh

> --On 14 February 2011 07:57:50 +0000 Alex Bligh <al...@alex.org.uk> wrote:
>
>>>> If I do "svn log ." in a directory, it does not list all changes made
>>>> to all files in that directory (as shown up "svn log <filename>"). I've
>>>> pasted an example at:
>>>> http://pastebin.com/SFYDtkBk
>>>> where r12062 does not show up in "svn log .", but does on the changed
>>>> file.
>>>>
>>>> svn diff . does the expected, and the file is not in svn:ignore.
>>>>
>>>> Is this deliberate and how do I get a recursive list of logs?
>>>
>>> Is the directory up to date? Try "svn up" first. Otherwise you'll only
>>> get logs up to the revision of the directory (shown with "svn info").
>>
>> Yes, the directory is up to date. In fact all changes were made in that
>> directory (not on another machine).
>

> Just because you committed the changes from that directory does not mean
> it is up to date. In fact, usually, after committing changes, your
> working copy has mixed revisions and is therefore not up to date. Please
> verify whether running "svn up" first fixes the problem.

It does indeed fix it, even though "svn up" merely reported
"At revision 12087." (i.e implied it didn't change anything); how
odd. - Thanks.

If I had done a "svn ci ." from one level down, would the working
copy have been consistent?

--
Alex Bligh

Cooke, Mark

unread,
Feb 14, 2011, 5:04:41 AM2/14/11
to Alex Bligh, Ryan Schmidt, us...@subversion.apache.org
> -----Original Message-----
> From: Alex Bligh [mailto:al...@alex.org.uk]
> Sent: 14 February 2011 08:09
> To: Ryan Schmidt
> Cc: us...@subversion.apache.org; Alex Bligh
> Subject: Re: svn log behaviour
>
> It does indeed fix it, even though "svn up" merely reported
> "At revision 12087." (i.e implied it didn't change anything); how
> odd. - Thanks.
>
> If I had done a "svn ci ." from one level down, would the working
> copy have been consistent?
>
Can I suggest you read the manual at:
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html

There is a section about mixed-revision repositories. In a nutshell,
'ci' only updates the files that have changed (having checked that the
others have not changed) but does NOT do an automatic update afterwards.
This means that only the files affected are at the new revision...

~ mark c

Alex Bligh

unread,
Feb 14, 2011, 5:51:42 AM2/14/11
to Cooke, Mark, Ryan Schmidt, us...@subversion.apache.org, Alex Bligh

--On 14 February 2011 10:04:41 +0000 "Cooke, Mark" <mark....@siemens.com>
wrote:

> Can I suggest you read the manual at:
> http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html
>
> There is a section about mixed-revision repositories. In a nutshell,
> 'ci' only updates the files that have changed (having checked that the
> others have not changed) but does NOT do an automatic update afterwards.
> This means that only the files affected are at the new revision...

OK. What I had failed to understand was that the log was (also?) a property
of the directory, rather than the file checked in. IE "svn log ." seems
to look at the log for the object "." (which includes the logs of
any objects beneath it in the hierarchy), rather than looking at the
logs for "." and the logs for any objects beneath it in the hierarchy
(a subtle difference). "svn diff" does that latter, and thus was showing
all the differences up. I have to say the red book doesn't explain
that distinction particularly clearly. But now I know.

--
Alex Bligh

Reply all
Reply to author
Forward
0 new messages