[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Commit fails on SVN 1.5.0

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: Fri, 25 Jan 2008 13:11:55 -0600

Please remember to reply to the list also, not just to me privately.

On Jan 25, 2008, at 02:17, Lasse Vågsæther Karlsen wrote:

> On Jan 25, 2008 12:13 AM, Ryan Schmidt wrote:
>> On Jan 24, 2008, at 11:31, Robert Dailey wrote:
>> > First of all I would like to note that I use TortoiseSVN to control
>> > Subversion, so if possible please reference solutions in regards to
>> > the GUI interface and avoid command line syntax. I'm not familiar
>> > with the command line at all. Thank you.
>> Since I don't use Windows or TortoiseSVN I can't accommodate you. :)
>> > I'm currently using the latest nightly build of TortoiseSVN, which
>> > utilizes SVN 1.5.0.
>> >
>> > Currently I have a working copy that, at some nested level down the
>> > directory tree, has an external link to a different location in the
>> > same repository as the working copy links to. When I have
>> > modifications in both the parts of my working copy that are not
>> > externally linked AND also in the parts that are externally linked,
>> > any attempt to commit yields the following output in the commit
>> > dialog:
>> >
>> > Command: Commit
>> > Error: Are all the targets part of the same working copy?
>> > Error: Unable to lock 'C:\IT\personal\rocket_test\engine\boblib
>> \input'
>> > Error: Please execute the "Cleanup" command.
>> > Finished!:
>> >
>> > I remember in SVN 1.4.5 this never used to happen. I was always
>> > able to commit external link files and working copy files
>> > simultaneously through one commit. Am I doing something wrong? Any
>> > help is greatly appreciated. Thanks in advance!
>> I'm surprised this used to work. I don't think it was ever supposed
>> to work that way. I thought you were supposed to have to commit
>> changes in external directories separately from everything else. See:
>> http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
>> "The support that exists for externals definitions in Subversion is
>> less than ideal, though. ... [T]he working copies created via the
>> externals definition support are still disconnected from the primary
>> working copy (on whose versioned directories the svn:externals
>> property was actually set). And Subversion still only truly operates
>> on non-disjoint working copies. So, for example, if you want to
>> commit changes that you've made in one or more of those external
>> working copies, you must run svn commit explicitly on those working
>> copies -- committing on the primary working copy will not recurse
>> into any external ones."
>> Maybe Subversion 1.5 is enforcing this more strictly.
>> Or, another theory: Maybe TortoiseSVN includes a workaround for this
>> situation, which broke in Subversion 1.5.
>> You should report this problem on a TortoiseSVN mailing list, and see
>> if they had a workaround for the problem which might need to be
>> updated to work with 1.5.
> If I'm not mistaken there are cases where, where the externals are
> part of the same repository, then Subversion might allow this to
> happen. I'm not 100% sure this was the case, but when trying to
> help a friend getting things to work I think this is what he had
> set up. All I know is that when we cleared out the working folder
> and did a new checkout, it required separate commits and he wanted
> it back to the way it was.
> I'm sorry I can't provide more details.

I have always used just a single repository for everything, and I
don't think it works the way you describe. As the book says, the
external is a disjointed working copy from the main working copy and
the two cannot be committed at once.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-25 20:12:41 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.