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

Re: 'svn ls' not consistent with w.c. status? (1.4.3)

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-06-06 23:28:35 CEST

On Jun 6, 2007, at 15:37, Toby Thain wrote:

> On 6-Jun-07, at 4:01 PM, Hari Kodungallur wrote:
>> On 6/6/07, Blair Zajac wrote:
>>> Toby Thain wrote:
>>> > ... after committing r12 from this working copy (Subclipse), I
>>> tried:
>>> >
>>> > $ svn ls -v
>>> >...
>>> > I was surprised that none of the files updated in r12 were
>>> marked as
>>> > such, so I did:
>>> >
>>> > $ svn up
>>> > At revision 12.
>>> >
>>> > Then 'ls' showed what I expected:
>>> >...
>>> > Is this normal behaviour?
>>> Yes, you never pull updates down from the server for files that
>>> were not
>>> committed.
>>> See the mixed revision working copy portion of the Svn boko.
>>> http://svnbook.red-bean.com/en/1.2/svn.basic.in-
>>> action.html#svn.basic.in-action.mixedrevs
>> "svn ls" does not work on the working copy, according to the help.
>> ...
>> Meaning it should have reflected the revisions in the repository
>> (which in this case should have been 12). I think svn probably
>> also appends the revision of the current directory. When you do a
>> commit of a file, the revision of the directory remains the same
>> (mixed revisions and such). So in the above case, since TARGET is
>> not given, I believe, svn uses <URL>@11, because the working
>> directory is at rev 11.
> Is it really at r11 when a commit of r12 has just been made in it?

Yes, it really is. You did not commit any change to the directory;
rather, you just committed a change to a file in the directory. In
your working copy, that file is now at r12, but the other files you
did not commit, and the directory they're in, remain at whatever
revision they were at previously, perhaps r11, perhaps an earlier

>> Not sure whether defaulting TARGET to URL@REV is intentional, but
>> it could be a bug. [I am copying this email to dev@]

I believe this is intentional and not a bug.

>> Also, to comment on Blair's point, I think even if we are to
>> consider mixed revisions, it is an issue. If you made the commit
>> from your working copy, you expect that your working copy will
>> reflect that commit that you made

The working copy does reflect the commit you just made. But the "svn
ls" command, as explained, shows what's in the repository, not what's
in your working copy, and it works by default on the revision of the
directory you're in when you run the command.

> Yes, that was also my expectation. This isn't a mixed-rev w.c., so
> what I saw was at least counter-intuitive, if not actually incorrect.

Most working copies are mixed-revision. At the very latest, your
working copy became mixed-revision as soon as you committed, as I
explained above.

> Mark may be on to something by pointing the finger at SVNKit (which
> I think is what my Subclipse is using).

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 6 23:29:26 2007

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.