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.
Received on 2011-02-22 16:10:51 CET