On Thu, May 2, 2013 at 8:59 AM, Bay Karsten (BEG/ESR3)
<karsten....@de.bosch.com> wrote:
> Hi SVN users,
>
> I got no answer until now.
>
> I think the problem described below is a bug.
> Do you agree?
>
> Is it too complex to understand?
> If something is inexplicit please let me know.
>
> Mit freundlichen Grüßen / Best regards
>
> Karsten Bay
>
> Bosch Engineering GmbH
> BEG/ESR3
> Postfach 13 50
> 74003 Heilbronn
> GERMANY
>
> karsten....@de.bosch.com
>
> Sitz: Abstatt, Registergericht: Amtsgericht Stuttgart HRB 108931
> Aufsichtsratsvorsitzender: Rolf Leonhard; Geschäftsführung: Bernhard Bihr,
> Hanno Miorini
> Umsatzsteuer-Identnummer (VAT no.): DE 18 21 37 093, Steuernummer:
> 99012/08009
>
>
> _____________________________________________
> Von: Bay Karsten (BEG/ESR3)
> Gesendet: Freitag, 12. April 2013 15:49
> An: 'users@subversion.apache.org'
> Betreff: "svn status -u" and svn:externals - bug?
>
>
> Hi SVN users,
>
> I searched for this problem in the open issues but could not find a similar
> problem.
> Can you help me to find out if this is a known problem/bug?
>
> I have a repository with a few svn:externals. Some of them point to a
> specific revision (e.g. trunk@8) of their repository.
> When I look up with "svn status -u" if I have to do an update SVN shows me
> files out of this external repositories which should be reputedly newer on
> the server.
> The problem is that the external repository has newer revisions with a newer
> version of this file but this should not play a role for my repository
> (because of the trunk@8).
>
> Example extract of the console output:
> ----------
> C:\WORKSPACE\SVN>svn propget svn:externals
> file://???/SW/trunk@8 SW
>
> C:\WORKSPACE\SVN>svn status -u
> X SW
> Status against revision: 117
>
> Performing status on external item at 'SW':
> * 8 C:\WORKSPACE\SVN\SW\Code.c
> Status against revision: 13
> ----------
>
> I looked in the source code and tried to find the reason for this behavior.
> I think that the problem is in status-cmd.c svn_cl__status().
> There I found this piece of code which may cause this problem:
> /* We want our -u statuses to be against HEAD. */
> rev.kind = svn_opt_revision_head;
> In my opinion in the case of external repository with fixed revision the
> check should be performed against this revision?
>
>
> A similar problem exists if I do an update on a subfolder (one which is
> added by svn:externals and points to a specific revision) of my repository
> then the HEAD revision of this folder is checked out.
>
>
> If needed I can try to do a repro-template.bat.
> Normally I work with TortoiseSVN and SVN Notifier but because of the problem
> I tried to reproduce it on the command line.
>
>
> Windows 7 - Subversion 1.7.9
>
Hi Karsten,
It looks like an issue to me. If nobody challenges your findings
within the next couple of hours, feel free to file an issue.
However, I found this issue which looks exactly like what you're seeing:
http://subversion.tigris.org/issues/show_bug.cgi?id=3659 (Not
correct statuses for svn externals)
It's closed as fixed in 1.7.0. So either there was a regression since
1.7.0, or this issue wasn't fixed after all. I'm not sure if there is
a regression test for this.
Are you sure you used a 1.7.9 client for this?
You also pose a second question, related to updating a subfolder of an
external. But that is a different issue. The problem here is that,
once inside an external, svn doesn't really know that it's inside this
(pegged) external. It's just a (embedded) checkout as far as that 'svn
update' operation is concerned. I agree it's also a problem, but it's
more a design issue. For reference, here are some dev@ discussions
related to this:
http://svn.haxx.se/dev/archive-2010-08/0529.shtml ([RFC] 'External'
and 'Switched': common ground)
http://svn.haxx.se/dev/archive-2011-05/0104.shtml (Feature
wish/request: [--externals MODE] switch on update)
But I can't find an issue in the issue tracker about this ...
--
Johan
