You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jason Sachs <jm...@gmail.com> on 2011/02/22 15:52:05 UTC
bug in mixed-version detection + single-file externals
I'm having trouble with single-file externals, and I suspect this is a
bug in svn rather than in my setup.
The file externals work fine except for one thing: they cause svn to
see my checkout incorrectly as a mixed-revision checkout. If I do a
clean checkout, and type "svnversion", instead of seeing a single
number, I see {rev1}:{rev2} where {rev1} is the earliest version of
the file external, and {rev2} is the actual version of the working
copy. (This does not occur with directory externals.)
The problem is not just confined to svnversion: more seriously, this
is preventing us from doing a --reintegrate merge, since svn complains
that I have a mixed-revision working copy.
This problem occurs both in command-line svn and in TortoiseSVN.
I am using
svn, version 1.6.15 (r1038135)
compiled Nov 25 2010, 16:55:30
TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01
this is running on Windows XP
Is this a known bug? Is there a workaround other than not using file externals?
Re: bug in mixed-version detection + single-file externals
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Recent trunk on Debian.
Jason Sachs wrote on Tue, Feb 22, 2011 at 16:04:24 -0500:
> Shall we trade version info?
>
> I'm running on WinXP SP3, with svn command line from Wandisco
> binaries, svn version 1.6.15 (r1038135) compiled Nov 25 2010, 16:55:30
>
> On Tue, Feb 22, 2011 at 2:09 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Having fixed that (the fix was to use "--" in argv), I get this output
> > with your second script:
> >
> > ...
> > Fetching external item into 'w_bar/blah.txt'
> > svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a directory
> > ['svnversion', 'w_bar']
> > 7
> > ['svn', 'merge', '--reintegrate', 'file:////tmp/svn/repos/bar/branches/br1', 'w_bar']
> > --- Merging differences between repository URLs into 'w_bar':
> > A w_bar/hohum.txt
> > ...
> >
Re: bug in mixed-version detection + single-file externals
Posted by Jason Sachs <jm...@gmail.com>.
Shall we trade version info?
I'm running on WinXP SP3, with svn command line from Wandisco
binaries, svn version 1.6.15 (r1038135) compiled Nov 25 2010, 16:55:30
On Tue, Feb 22, 2011 at 2:09 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Having fixed that (the fix was to use "--" in argv), I get this output
> with your second script:
>
> ...
> Fetching external item into 'w_bar/blah.txt'
> svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a directory
> ['svnversion', 'w_bar']
> 7
> ['svn', 'merge', '--reintegrate', 'file:////tmp/svn/repos/bar/branches/br1', 'w_bar']
> --- Merging differences between repository URLs into 'w_bar':
> A w_bar/hohum.txt
> ...
>
Re: bug in mixed-version detection + single-file externals
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jason Sachs wrote on Tue, Feb 22, 2011 at 12:02:55 -0500:
> > 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:
>
> I had to use "blah.txt -r 3 ^/foo/trunk/blah.txt" rather than "-r 3
> ^/foo/trunk/blah.txt blah.txt" as it wouldn't work as a command-line
> argument. Perhaps someone can help me rewrite.
Having fixed that (the fix was to use "--" in argv), I get this output
with your second script:
...
Fetching external item into 'w_bar/blah.txt'
svn: URL 'file:///tmp/svn/repos/foo/trunk/blah.txt' refers to a file, not a directory
['svnversion', 'w_bar']
7
['svn', 'merge', '--reintegrate', 'file:////tmp/svn/repos/bar/branches/br1', 'w_bar']
--- Merging differences between repository URLs into 'w_bar':
A w_bar/hohum.txt
...
Re: bug in mixed-version detection + single-file externals
Posted by Jason Sachs <jm...@gmail.com>.
> 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:
I had to use "blah.txt -r 3 ^/foo/trunk/blah.txt" rather than "-r 3
^/foo/trunk/blah.txt blah.txt" as it wouldn't work as a command-line
argument. Perhaps someone can help me rewrite.
Re: bug in mixed-version detection + single-file externals
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.
...
]]]
Re: bug in mixed-version detection + single-file externals
Posted by Jason Sachs <jm...@gmail.com>.
>> 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.
Re: bug in mixed-version detection + single-file externals
Posted by Jason Sachs <jm...@gmail.com>.
> The problem with reintegrate merges you are describing sounds
> quite serious and should be added to the issue tracker.
I had recently submitted it (but didn't know about posting to this list first).
See http://subversion.tigris.org/issues/show_bug.cgi?id=3816
> Can you share more information to allow others to reproduce this problem?
> What do your file externals definitions look like? Are you pinning externals
> to known revisions or are they coming from URLS in the HEAD revision?
They are pinned to known revisions, they look like "-r 12345
^/path/to/my/branch/somefile somefile"
(I never use the HEAD revision)
> 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)
Re: bug in mixed-version detection + single-file externals
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 22, 2011 at 09:52:05AM -0500, Jason Sachs wrote:
> I'm having trouble with single-file externals, and I suspect this is a
> bug in svn rather than in my setup.
>
> The file externals work fine except for one thing: they cause svn to
> see my checkout incorrectly as a mixed-revision checkout. If I do a
> clean checkout, and type "svnversion", instead of seeing a single
> number, I see {rev1}:{rev2} where {rev1} is the earliest version of
> the file external, and {rev2} is the actual version of the working
> copy. (This does not occur with directory externals.)
>
> The problem is not just confined to svnversion: more seriously, this
> is preventing us from doing a --reintegrate merge, since svn complains
> that I have a mixed-revision working copy.
File externals are quite broken in 1.6.
Several known issues already exist:
can't remove file externals
http://subversion.tigris.org/issues/show_bug.cgi?id=3351
Disallow modifications to file externals with specific revision
http://subversion.tigris.org/issues/show_bug.cgi?id=3563
file externals can break commits of WC->WC copies
http://subversion.tigris.org/issues/show_bug.cgi?id=3589
The problem with reintegrate merges you are describing sounds
quite serious and should be added to the issue tracker.
Can you share more information to allow others to reproduce this problem?
What do your file externals definitions look like? Are you pinning externals
to known revisions or are they coming from URLS in the HEAD revision?
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!).
> This problem occurs both in command-line svn and in TortoiseSVN.
> I am using
> svn, version 1.6.15 (r1038135)
> compiled Nov 25 2010, 16:55:30
>
> TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01
>
> this is running on Windows XP
>
> Is this a known bug? Is there a workaround other than not using file externals?
I hope that a workaround exists. Otherwise we might have to
add an option like --allow-mixed-revisions to svn merge in 1.6.x
(which already exists in trunk, a.k.a 1.7, for another reason)
in a 1.6.x patch release to allow people to work around this.