[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: Hari Kodungallur <hkodungallur_at_gmail.com>
Date: 2007-06-06 21:01:23 CEST

On 6/6/07, Blair Zajac <blair@orcaware.com> wrote:
>
> Toby Thain wrote:
> > ... after committing r12 from this working copy (Subclipse), I tried:
> >
> > $ svn ls -v
> > 2 emil 17987 Jun 02 12:41 GPL
> > 11 emil 1136 Jun 05 19:00 Makefile
> > 11 emil 1616 Jun 05 19:00 README
> > 11 emil 2293 Jun 05 19:00 addr_calc.c
> > 11 emil 5406 Jun 05 19:00 disasm.c
> > 11 emil 6359 Jun 05 19:00 emul.c
> > 11 emil 4718 Jun 05 19:00 in_out.c
> > 11 emil 3046 Jun 05 19:00 loader.c
> > 11 emil 1814 Jun 05 19:00 reg_flags.h
> > 11 emil 1163 Jun 05 19:00 version.h
> >
> > 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:
> >
> > $ svn ls -v
> > 2 emil 17987 Jun 02 12:41 GPL
> > 12 toby 1140 Jun 05 20:40 Makefile
> > 11 emil 1616 Jun 05 19:00 README
> > 11 emil 2293 Jun 05 19:00 addr_calc.c
> > 11 emil 5406 Jun 05 19:00 disasm.c
> > 12 toby 6345 Jun 05 20:40 emul.c
> > 12 toby 4786 Jun 05 20:40 in_out.c
> > 12 toby 3128 Jun 05 20:40 loader.c
> > 11 emil 1814 Jun 05 19:00 reg_flags.h
> > 11 emil 1163 Jun 05 19:00 version.h
> >
> > 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.

$> svn help ls
list (ls): List directory entries in the repository.
usage: list [TARGET[@REV]...]

  List each TARGET file and the contents of each TARGET directory as
  they exist in the repository. If TARGET is a working copy path, the
  corresponding repository URL will be used. If specified, REV determines
  in which revision the target is first looked up.

  The default TARGET is '.', meaning the repository URL of the current
  working directory.

  With --verbose, the following fields will be shown for each item:

    Revision number of the last commit
    Author of the last commit
    If locked, the letter 'O'. (Use 'svn info URL' to see details)
    Size (in bytes)
    Date and time of the last commit

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.

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

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
(and I think that is the whole point of mixed revisions).

Regards,
-Hari Kodungallur
Received on Wed Jun 6 21:01:37 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.