You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Toby Thain <to...@smartgames.ca> on 2007/06/06 12:45:24 UTC
'svn ls' not consistent with w.c. status? (1.4.3)
... 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?
--Toby
$ svn --version
svn, version 1.4.3 (r23084)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Toby Thain <to...@smartgames.ca>.
On 6-Jun-07, at 7:02 PM, Ryan Schmidt wrote:
> On Jun 6, 2007, at 16:56, Toby Thain wrote:
>
>> On 6-Jun-07, at 6:28 PM, Ryan Schmidt wrote:
>>
>>>>> 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.
>>
>> That would explain what I saw. But I found it surprising enough
>> that I posted here...
>>
>>>> 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.
>>
>> Alright. So it's normal that running 'svn up' (which had no
>> updates to bring down) would change the view of 'ls'?
>
> Let's say the revision of your directory was r11. You committed a
> file which created r12 in the repository. "svn ls" uses the
> revision of the directory you're in when it queries the repository,
> by default. So "svn ls" would show you info about r11 of the
> repository.
OK.
>
> "svn up" will bring all elements in the directory, including the
> directory, up to the HEAD revision of the repository, which, if you
> haven't made any other changes, is still r12. "svn ls" will now
> tell you baout revision 12 of the repository.
>
>
>> After the 'svn up', is it a mixed rev w.c. or not? And what's the
>> revision of . after the 'svn up'? It would still be r11, right? So
>> why did ls suddenly show me something new? I'm still not clear.
>> But I may just be dense.
>
> Use "svnversion" to determine if you're in a mixed-revision working
> copy. If you are, it will print more than one number.
>
> Also try "svn info" which will show you the revision of the item on
> which you ran the command, or the current directory if you did not
> specify.
>
> If you ran "svn up" at the root of your working copy, then your
> entire working copy is of a single revision -- until you next
> commit something.
I see this now - that a commit causes a mixed rev w.c.
> If, however, you ran "svn up" in a subdirectory of your working
> copy, then everything in that subdirectory is of a single revision,
> but its parent directory and any other subdirectories may well
> still be of other revisions.
Yes, that part I already understood.
Thanks very much for the explanations.
--Toby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 6, 2007, at 16:56, Toby Thain wrote:
> On 6-Jun-07, at 6:28 PM, Ryan Schmidt wrote:
>
>>>> 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.
>
> That would explain what I saw. But I found it surprising enough
> that I posted here...
>
>>> 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.
>
> Alright. So it's normal that running 'svn up' (which had no updates
> to bring down) would change the view of 'ls'?
Let's say the revision of your directory was r11. You committed a
file which created r12 in the repository. "svn ls" uses the revision
of the directory you're in when it queries the repository, by
default. So "svn ls" would show you info about r11 of the repository.
"svn up" will bring all elements in the directory, including the
directory, up to the HEAD revision of the repository, which, if you
haven't made any other changes, is still r12. "svn ls" will now tell
you baout revision 12 of the repository.
> After the 'svn up', is it a mixed rev w.c. or not? And what's the
> revision of . after the 'svn up'? It would still be r11, right? So
> why did ls suddenly show me something new? I'm still not clear. But
> I may just be dense.
Use "svnversion" to determine if you're in a mixed-revision working
copy. If you are, it will print more than one number.
Also try "svn info" which will show you the revision of the item on
which you ran the command, or the current directory if you did not
specify.
If you ran "svn up" at the root of your working copy, then your
entire working copy is of a single revision -- until you next commit
something. If, however, you ran "svn up" in a subdirectory of your
working copy, then everything in that subdirectory is of a single
revision, but its parent directory and any other subdirectories may
well still be of other revisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Toby Thain <to...@smartgames.ca>.
On 6-Jun-07, at 6:28 PM, Ryan Schmidt wrote:
> ...
>>> 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.
That would explain what I saw. But I found it surprising enough that
I posted here...
>
>> 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.
Alright. So it's normal that running 'svn up' (which had no updates
to bring down) would change the view of 'ls'?
After the 'svn up', is it a mixed rev w.c. or not? And what's the
revision of . after the 'svn up'? It would still be r11, right? So
why did ls suddenly show me something new? I'm still not clear. But I
may just be dense.
--Toby
>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
revision.
>> 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
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
revision.
>> 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Toby Thain <to...@smartgames.ca>.
On 6-Jun-07, at 4:01 PM, Hari Kodungallur wrote:
> On 6/6/07, Blair Zajac <bl...@orcaware.com> 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?
>
> 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
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.
Mark may be on to something by pointing the finger at SVNKit (which I
think is what my Subclipse is using).
--Toby
> (and I think that is the whole point of mixed revisions).
>
> Regards,
> -Hari Kodungallur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Toby Thain <to...@smartgames.ca>.
On 6-Jun-07, at 4:01 PM, Hari Kodungallur wrote:
> On 6/6/07, Blair Zajac <bl...@orcaware.com> 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?
>
> 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
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.
Mark may be on to something by pointing the finger at SVNKit (which I
think is what my Subclipse is using).
--Toby
> (and I think that is the whole point of mixed revisions).
>
> Regards,
> -Hari Kodungallur
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Hari Kodungallur <hk...@gmail.com>.
On 6/6/07, Blair Zajac <bl...@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
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Hari Kodungallur <hk...@gmail.com>.
On 6/6/07, Blair Zajac <bl...@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
Re: 'svn ls' not consistent with w.c. status? (1.4.3)
Posted by Blair Zajac <bl...@orcaware.com>.
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
Regards,
Blair
--
Blair Zajac, Ph.D.
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org