Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 22 Feb 2011 18:45:52 +0200
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Jason Sachs <jmsachs@gmail.com>
Cc: users@subversion.apache.org
Subject: Re: bug in mixed-version detection + single-file externals
Message-ID: <20110222164552.GD9334@daniel3.local>
References: <AANLkTi=FQrqNwQqNpYudL0aK0zzQERppyUxEn0r_BXN7@mail.gmail.com>
 <20110222151013.GN11578@ted.stsp.name>
 <AANLkTi=LxueQnWb2=u_-L8o87n3QG+VsFsoUVRBMvRyB@mail.gmail.com>
 <AANLkTinx8FJNjBk33fpS3gaAZNZY5643s4oMgjWXLYa1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTinx8FJNjBk33fpS3gaAZNZY5643s4oMgjWXLYa1@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

Jason Sachs wrote on Tue, Feb 22, 2011 at 11:07:38 -0500:
> >> If you could write a script that starts with an empty repository, gets a
> >> working copy, and runs svn commands until the problem triggers, that would
> >> help greatly (and avoids any ambiguity in the problem description!).
> >
> > See attached python script (tested only on WinXP + Python 2.6.5)
> >
> 
> Script output:
> =========
> C:\tmp\svn\ext1>python trybug.py
> Checked out revision 0.
> A         C:\tmp\svn\ext1\working\foo
> A         C:\tmp\svn\ext1\working\foo\trunk
> A         C:\tmp\svn\ext1\working\bar
> A         C:\tmp\svn\ext1\working\bar\trunk
> A         working\foo\trunk\blah.txt
> Adding         working\bar
> Adding         working\bar\trunk
> Adding         working\foo
> Adding         working\foo\trunk
> Adding         working\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 1.
> Sending        working\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 2.
> Sending        working\foo\trunk\blah.txt
> Transmitting file data .
> Committed revision 3.
> property 'svn:externals' set on 'working\bar\trunk'
> Sending        working\bar\trunk
> 
> Committed revision 4.
> 
> Fetching external item into 'working\bar\trunk\blah.txt'
> E    working\bar\trunk\blah.txt
> Updated external to revision 1.
> 
> Updated to revision 4.
> 1:4
> 
> =========
> This just creates a sample repos + working copy and illustrates the
> problem with svnversion, which should print out "4" but instead prints
> out "1:4".
> 
> I didn't create a testcase for performing a merge, that's more complex
> than I can deal with right now.

With a trunk build, I get a warning and the right svnversion output:

[[[
% python2.6 trybug.py
Checked out revision 0.
A         /tmp/svn/working/foo
A         /tmp/svn/working/foo/trunk
A         /tmp/svn/working/bar
A         /tmp/svn/working/bar/trunk
A         working/foo/trunk/blah.txt
Adding         working/bar
Adding         working/bar/trunk
Adding         working/foo
Adding         working/foo/trunk
Adding         working/foo/trunk/blah.txt
Transmitting file data .
Committed revision 1.
Sending        working/foo/trunk/blah.txt
Transmitting file data .
Committed revision 2.
Sending        working/foo/trunk/blah.txt
Transmitting file data .
Committed revision 3.
property 'svn:externals' set on 'working/bar/trunk'
Sending        working/bar/trunk

Committed revision 4.
svn: Unrecognized format for the relative external URL 'blah.txt'.
4
]]]

I'm not sure what causes this, but for reference here's the output of
'svn help propset' from trunk:
[[[
...
    svn:externals  - A newline separated list of module specifiers,
      each of which consists of a URL and a relative directory path,
      similar to the syntax of the 'svn checkout' command:
        http://example.com/repos/zig foo/bar
      A revision to check out can optionally be specified to pin the
      external to a known revision:
        -r25 http://example.com/repos/zig foo/bar
      To unambiguously identify an element at a path which has been
      deleted (possibly even deleted multiple times in its history),
      an optional peg revision can be appended to the URL:
        -r25 http://example.com/repos/zig@42 foo/bar
      Relative URLs are indicated by starting the URL with one
      of the following strings:
        ../  to the parent directory of the extracted external
        ^/   to the repository root
        //   to the scheme
        /    to the server root
      The ambiguous format 'relative_path relative_path' is taken as
      'relative_url relative_path' with peg revision support.
      Lines in externals definitions starting with the '#' character
      are considered comments and are ignored.
      Subversion 1.4 and earlier only support the following formats
      where peg revisions can only be specified using a -r modifier
      and where URLs cannot be relative:
        foo             http://example.com/repos/zig
        foo/bar -r 1234 http://example.com/repos/zag
      Use of these formats is discouraged. They should only be used if
      interoperability with 1.4 clients is desired.
...
]]]