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

Re: "svn commit" followed by "svn log" doesn't show new revision

From: Niels Skou Olsen <nso_at_manbw.dk>
Date: 2004-11-17 22:37:28 CET

"Mark" <mark@msdhub.com> writes:

> You'll find that if Ben says it, it's probably true.

I know that -- and therefore I only took the liberty to doubt yours and
Dale's remarks about directory semantics: ;-)

>> "Dale Worley" <dworley@pingtel.com> wrote:
>> After thinking about it some more, I suspect that the answer is this: What
>> files are in a directory is *not* "the contents of the directory".
>> [...]
>> The information about the directory that is connected to *its* revision are
>> its permissions (I think), and above all, its properties.
>> [...]
>> Thus, committing a file addition is not a change to the containing
>> directory -- it is only a change to the pathname of the file.
>>> "Mark" <mark@msdhub.com> wrote:
>>> That's exactly my experience. Committing a file doesn't bump the revnum of
>>> the containing directory, just the file.

> Anyway, committing -anything- creates a new revision in the REPOSITORY, but
> that's not what I was referring to when I said "bump". The working copy
> keeps track of the revision of each object contained within, and while
> committing a file (or a prop on a file/directory) updates that object to
> HEAD, nothing that wasn't committed gets updated to HEAD.

OK, to paraphrase: adding file F to directory D and commiting creates a new
revision in the repository but does not update D's BASE revision. We
already agreed that this is how Subversion actually works, but I
misinterpreted yours and Dale's explanations to mean that adding F to D
doesn't change D in the repository. Sorry 'bout that.

This brings me back to the original subject of this thread: After adding F
to D and committing, the repository's HEAD is newer than the working copy's
BASE for D. So we have a situation where "svn update" on D will actually
silently update the working copy (by updating BASE), but "svn status -u"
will not indicate this is going to happen. And furthermore, an "svn log"
before and after the "svn update" will yield different output. As I have
said earlier this is confusing and counter intuitive. Perhaps "svn status
-u" should emit a warning that a directory is "semi-out-of-date".

> Aside note to Ben: in "How Working Copies Track the Repository" the text
> refers to files only, such as "each file in a working directory" and
> "working file", when there are entries for directories too, and they are
> tracked in the same way.

I agree that this section should cover directories as well. Especially the
state "Locally changed, and out-of-date" has some interesting subtleties
with respect to the behaviour of commit/update:

 1. Committing directory changes is handled differently from files, when
    the working copy is out of date. For directories the commit succeeds,
    and for files it fails with the "Out of date" error message.

 2. When committing a directory change, the directory's BASE revision is
    not updated, and "svn log" will thus not show the new revision. When
    committing a file change, the file's BASE revision *is* updated, and
    "svn log" *will* show the new revision.

I am sure that I will not be the last newbie to be confused by this.

Best regards,

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 22:38:31 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.