Switch and svn:externals

[Lachlan O'Dea <od...@ca.com>]

I'm having some difficulty when using svn switch on directories with an 
svn:externals property. Client is 1.0.4, server 1.0.1. Is there a 
preferred method of doing this?

I want to switch to another directory that has different svn:externals. 
This does change the property, but it does not seem to correctly switch 
the directories that were already checked out via the previous 
externals.

I can switch each external directory individually, but this tends to 
cause problems when trying to do things like svn update from the top, 
since the externals property is out of sync with what's checked out. 
Messages like "svn: Working copy 'blah' not locked". It can also be 
somewhat laborious to switch each one.

I think the preferred option for a switch would be for svn to detect if 
the new svn:externals has any references to the same directories as the 
original, but with different URLs. If so, it should switch these 
directories automatically. There are also tricky cases where say the 
directory you switch to removes an externals entry but contains a 
directory with the same name.

--
Lachlan O'Dea
Computer Associates
Senior Software Engineer
tel: +61 3 8416 5627
fax: +61 3 8416 5810
mobile: +61 412 390 650
odela01@ca.com

Relax and enjoy your shoes!

Re: Switch and svn:externals

[Ross Mark <ro...@controllingedge.com.au>]

kfogel@collab.net wrote:

>Is there a way to predict in advance whether the 'switch' should or
>not fail, perhaps by comparing repository UUIDs from the .svn/entries
>files?
>
>I like the general shape of your solution, but feel edgy about trying
>a command to see if it fails.  It seems like in this case we ought to
>know whether a switch would work in the first place...
>
>  
>
This was the main reason for not submitting the patch earlier as I 
didn't like the fact that an unlock had to be called as it might hide 
other problems.  My knowledge of svn's internals is basically 
non-existent and I took a straight hack approach to solving the problem. 
If there was an easy way to compare the repository UUID entries before 
trying the switch then I think it would probably prevent the need for 
the cleanup.

>>I was going to wait until 1.1 was fully released before trying to
>>submit the patch.
>>    
>>
>
>The trunk is still under development as usual, of course, but if you
>want to wait until 1.1 is out just to simplify things, that's fine.
>
>-Karl
>  
>
My initial patch was for the 1.0.5 line but I did also have a version 
that worked with a pre 1.1. I'll confirm that it still works and submit 
it. Possibly someone else is able to add the UUID comparison code.

Ross


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Switch and svn:externals

[kf...@collab.net]

Ross Mark <ro...@controllingedge.com.au> writes:
> I have been hesitant to submit the patch to the dev list as I'm not
> sure the logic would be approved of as it goes along the following
> lines.
> If (wc->url != external->url)
>     if (svn switch external->url  fails)
>     {
>        svn cleanup wc
>        Do existing delete and clean checkout.
>     }
> The logic is a bit more complicated than that but not much. What I'm
> concerned about is the call to svn cleanup which is required because
> svn switch would leave the wc locked if it failed.

Is there a way to predict in advance whether the 'switch' should or
not fail, perhaps by comparing repository UUIDs from the .svn/entries
files?

I like the general shape of your solution, but feel edgy about trying
a command to see if it fails.  It seems like in this case we ought to
know whether a switch would work in the first place...

> I was going to wait until 1.1 was fully released before trying to
> submit the patch.

The trunk is still under development as usual, of course, but if you
want to wait until 1.1 is out just to simplify things, that's fine.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Switch and svn:externals

[Ross Mark <ro...@controllingedge.com.au>]

Lachlan O'Dea wrote:

> I'm having some difficulty when using svn switch on directories with 
> an svn:externals property. Client is 1.0.4, server 1.0.1. Is there a 
> preferred method of doing this?
>
> I want to switch to another directory that has different 
> svn:externals. This does change the property, but it does not seem to 
> correctly switch the directories that were already checked out via the 
> previous externals.
>
> I can switch each external directory individually, but this tends to 
> cause problems when trying to do things like svn update from the top, 
> since the externals property is out of sync with what's checked out. 
> Messages like "svn: Working copy 'blah' not locked". It can also be 
> somewhat laborious to switch each one.
>
Version 1.1 includes a patch (r10005 and r10006) which fixed this. It 
was a client issue in that when it tried to delete your wc, in order to 
checkout the new svn:externals entry, it did a non recursive lock and 
then complained that the sub directories weren't locked.

With 1.1 the changes in svn:externals should be detected and your 
working copy updated correctly. I haven't check the 1.1 version but my 
guess is that it will have the same behavior as the 1.0 in which it does 
the update by deleting all the files in the sub dir and checking them 
out again. This is only if the url in the svn:external doesn't match the 
working copy. Its a real sledgehammer approach that will work (unless 
you have local mods you need merged). Locally we used a patched version 
of the 1.0 which internally does an 'svn switch' and if that fails it 
reverts to the delete and checkout. In our cases this is almost always 
the correct thing to do as the most common change to the svn:externals 
entries is to change the tag a wc points to. Deleting a 16M wc and 
checking it out again just because it references a new tag was a bit 
excessive.

I have been hesitant to submit the patch to the dev list as I'm not sure 
the logic would be approved of as it goes along the following lines.
If (wc->url != external->url)
    if (svn switch external->url  fails)
    {
       svn cleanup wc
       Do existing delete and clean checkout.
    }
The logic is a bit more complicated than that but not much. What I'm 
concerned about is the call to svn cleanup which is required because svn 
switch would leave the wc locked if it failed.

I was going to wait until 1.1 was fully released before trying to submit 
the patch.

Ross

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org