On 6-Jun-07, at 4:01 PM, Hari Kodungallur wrote:
> On 6/6/07, Blair Zajac <email@example.com> wrote:
> Toby Thain wrote:
> > ... after committing r12 from this working copy (Subclipse), I
> > $ 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
> See the mixed revision working copy portion of the Svn boko.
> "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).
> (and I think that is the whole point of mixed revisions).
> -Hari Kodungallur
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jun 9 16:08:22 2007