You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Aldrich <Da...@EU.NEC.COM> on 2010/03/11 16:11:42 UTC

Unexpected Externals behaviour in working copy

Hi

I have a question about externals. I tried the following scenario in my working copy:

1) Add an external definition to directory A, specifying subdirectory B
2) Commit directory A
3) Update directory A

I then see A/B populated

Then:

4) Edit external definition to directory A, specifying subdirectory C
5) Commit directory A
6) Update directory A

I then see A/C populated, but directory A/B remains in the wc.

If I checkout a new working copy, it shows A/C but not A/B, as expected.

So, in short, changing an external definition on a directory seems not to remove the previous external content from the committer's working copy.

I hope this makes sense. Please will someone explain?

Best regards

David

Re: Unexpected Externals behaviour in working copy

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 12, 2010, at 15:47, Les Mikesell wrote:

> On 3/12/2010 3:14 PM, Ryan Schmidt wrote:
>> 
>> On Mar 12, 2010, at 14:43, Les Mikesell wrote:
>> 
>>> What should happen to things that are added to a working copy some other way but aren't managed by subversion?  I don't think you want them deleted on an update.  After you've removed an external, how is subversion supposed to tell the difference between something it put there from the earlier external reference and something you copied in yourself?
>> 
>> "By keeping track of it," of course. It seems the fact that Subversion doesn't keep track of it is the bug.
> 
> But the point of externals is that they are kept track of somewhere else, not in the parent repo.  When you break the linkage to that 'somewhere else', how are you supposed to know anything about the contents.

Off the top of my head, Subversion could notice when you commit a change in the svn:externals property. If the svn:externals property used to pull an external into the directory foo, and you change the property so this no longer happens (including deleting the property), Subversion could check if the directory foo exists, and if so, if it is a working copy of the URL the external definition used to point to. If so, it could do what it does any other time it removes a directory: remove the files if they're not modified, keep them if they are (or are unversioned), delete empty directories.

That would be for the user doing the commit that changes or removes the external. For users updating, Subversion could notice the change in svn:externals on update, and act accordingly.

Re: Unexpected Externals behaviour in working copy

Posted by Les Mikesell <le...@gmail.com>.
On 3/12/2010 3:14 PM, Ryan Schmidt wrote:
>
> On Mar 12, 2010, at 14:43, Les Mikesell wrote:
>
>> On 3/12/2010 2:12 PM, Johan Corveleyn wrote:
>>>
>>
>>> Is there an entry in the issue tracker for this, if this is indeed
>>> considered a bug (I know there is one for the inability to remove file
>>> externals, but for this behavior of dir externals...)? Or is there no
>>> consensus that this is indeed a bug?
>>
>> What should happen to things that are added to a working copy some other way but aren't managed by subversion?  I don't think you want them deleted on an update.  After you've removed an external, how is subversion supposed to tell the difference between something it put there from the earlier external reference and something you copied in yourself?
>
> "By keeping track of it," of course. It seems the fact that Subversion doesn't keep track of it is the bug.

But the point of externals is that they are kept track of somewhere 
else, not in the parent repo.  When you break the linkage to that 
'somewhere else', how are you supposed to know anything about the contents.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Unexpected Externals behaviour in working copy

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 12, 2010, at 14:43, Les Mikesell wrote:

> On 3/12/2010 2:12 PM, Johan Corveleyn wrote:
>> 
> 
>> Is there an entry in the issue tracker for this, if this is indeed
>> considered a bug (I know there is one for the inability to remove file
>> externals, but for this behavior of dir externals...)? Or is there no
>> consensus that this is indeed a bug?
> 
> What should happen to things that are added to a working copy some other way but aren't managed by subversion?  I don't think you want them deleted on an update.  After you've removed an external, how is subversion supposed to tell the difference between something it put there from the earlier external reference and something you copied in yourself?

"By keeping track of it," of course. It seems the fact that Subversion doesn't keep track of it is the bug.

Re: Unexpected Externals behaviour in working copy

Posted by Les Mikesell <le...@gmail.com>.
On 3/12/2010 2:12 PM, Johan Corveleyn wrote:
>
>> Hi David,
>>
>> when I analysed externals in 1.6 about a year ago, that is what I
>> found. I consider it a bug.
>
> Is there an entry in the issue tracker for this, if this is indeed
> considered a bug (I know there is one for the inability to remove file
> externals, but for this behavior of dir externals...)? Or is there no
> consensus that this is indeed a bug?

What should happen to things that are added to a working copy some other 
way but aren't managed by subversion?  I don't think you want them 
deleted on an update.  After you've removed an external, how is 
subversion supposed to tell the difference between something it put 
there from the earlier external reference and something you copied in 
yourself?

-- 
   Les Mikesell
    lesmikesell@gmail.com

Re: Unexpected Externals behaviour in working copy

Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 12, 2010 at 3:21 PM, David Aldrich <Da...@eu.nec.com> wrote:
> Hi Neels
>
> Thanks very much for your answer. It clarified svn's behaviour with externals for me.
>
> With best regards
>
> David
>
> ________________________________________
> From: neels [neeels@gmail.com]
> Sent: 12 March 2010 14:08
> To: David Aldrich
> Cc: users@subversion.apache.org
> Subject: Re: Unexpected Externals behaviour in working copy
>
> On 12 March 2010 11:28, David Aldrich <Da...@eu.nec.com> wrote:
>> Hi
>>
>> I haven't had a reply to this question of mine yet. So I would like to rephrase it:
>>
>> Is it true that if I delete an external relating to a folder or file then svn will not automatically delete that folder/file from my local working copy?
>
> Hi David,
>
> when I analysed externals in 1.6 about a year ago, that is what I
> found. I consider it a bug.

Is there an entry in the issue tracker for this, if this is indeed
considered a bug (I know there is one for the inability to remove file
externals, but for this behavior of dir externals...)? Or is there no
consensus that this is indeed a bug?

Johan

RE: Unexpected Externals behaviour in working copy

Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi Neels

Thanks very much for your answer. It clarified svn's behaviour with externals for me.

With best regards

David

________________________________________
From: neels [neeels@gmail.com]
Sent: 12 March 2010 14:08
To: David Aldrich
Cc: users@subversion.apache.org
Subject: Re: Unexpected Externals behaviour in working copy

On 12 March 2010 11:28, David Aldrich <Da...@eu.nec.com> wrote:
> Hi
>
> I haven't had a reply to this question of mine yet. So I would like to rephrase it:
>
> Is it true that if I delete an external relating to a folder or file then svn will not automatically delete that folder/file from my local working copy?

Hi David,

when I analysed externals in 1.6 about a year ago, that is what I
found. I consider it a bug.

It's like this:
Dir externals are not removed from your WC, but they are "forgotten"
alright. If you remove the external prop, remove the external folder
and svn up, it is still gone.

File externals are not even capable of being forgotten! If you remove
the prop, remove the file, and then update, the damn thing *comes
back*! That's a stupid bug, no-one has gotten around to fix it yet.
You need a new checkout of the parent folder.

I attached a script that illustrates externals behaviour. I tested with 1.6.x.

~Neels

>
> This seems to be related to Subversion issue #3351 (although that issue only relates to file externals, not folder externals).
>
> It is seems that a fresh check out is required. Or is it ok to delete the 'external' folder/file in my wc using an operating system delete operation?
>
> Best regards
>
> David
>
> ________________________________________
> From: David Aldrich [David.Aldrich@eu.nec.com]
> Sent: 11 March 2010 16:11
> To: users@subversion.apache.org
> Subject: Unexpected Externals behaviour in working copy
>
> Hi
>
> I have a question about externals. I tried the following scenario in my working copy:
>
> 1) Add an external definition to directory A, specifying subdirectory B
> 2) Commit directory A
> 3) Update directory A
>
> I then see A/B populated
>
> Then:
>
> 4) Edit external definition to directory A, specifying subdirectory C
> 5) Commit directory A
> 6) Update directory A
>
> I then see A/C populated, but directory A/B remains in the wc.
>
> If I checkout a new working copy, it shows A/C but not A/B, as expected.
>
> So, in short, changing an external definition on a directory seems not to remove the previous external content from the committer's working copy.
>
> I hope this makes sense. Please will someone explain?
>
> Best regards
>
> David
>
>
>
>  Click https://www.mailcontrol.com/sr/nypLE7lZxS7TndxI!oX7UvIItv2OGGpTAw!IKZCqldsHAq!cPr+aidCSu5mXugUL!MaMXUtHUxa1yubdBaCdqw==  to report this email as spam.

Re: Unexpected Externals behaviour in working copy

Posted by neels <ne...@gmail.com>.
On 12 March 2010 11:28, David Aldrich <Da...@eu.nec.com> wrote:
> Hi
>
> I haven't had a reply to this question of mine yet. So I would like to rephrase it:
>
> Is it true that if I delete an external relating to a folder or file then svn will not automatically delete that folder/file from my local working copy?

Hi David,

when I analysed externals in 1.6 about a year ago, that is what I
found. I consider it a bug.

It's like this:
Dir externals are not removed from your WC, but they are "forgotten"
alright. If you remove the external prop, remove the external folder
and svn up, it is still gone.

File externals are not even capable of being forgotten! If you remove
the prop, remove the file, and then update, the damn thing *comes
back*! That's a stupid bug, no-one has gotten around to fix it yet.
You need a new checkout of the parent folder.

I attached a script that illustrates externals behaviour. I tested with 1.6.x.

~Neels

>
> This seems to be related to Subversion issue #3351 (although that issue only relates to file externals, not folder externals).
>
> It is seems that a fresh check out is required. Or is it ok to delete the 'external' folder/file in my wc using an operating system delete operation?
>
> Best regards
>
> David
>
> ________________________________________
> From: David Aldrich [David.Aldrich@eu.nec.com]
> Sent: 11 March 2010 16:11
> To: users@subversion.apache.org
> Subject: Unexpected Externals behaviour in working copy
>
> Hi
>
> I have a question about externals. I tried the following scenario in my working copy:
>
> 1) Add an external definition to directory A, specifying subdirectory B
> 2) Commit directory A
> 3) Update directory A
>
> I then see A/B populated
>
> Then:
>
> 4) Edit external definition to directory A, specifying subdirectory C
> 5) Commit directory A
> 6) Update directory A
>
> I then see A/C populated, but directory A/B remains in the wc.
>
> If I checkout a new working copy, it shows A/C but not A/B, as expected.
>
> So, in short, changing an external definition on a directory seems not to remove the previous external content from the committer's working copy.
>
> I hope this makes sense. Please will someone explain?
>
> Best regards
>
> David
>
>
>
>  Click https://www.mailcontrol.com/sr/nypLE7lZxS7TndxI!oX7UvIItv2OGGpTAw!IKZCqldsHAq!cPr+aidCSu5mXugUL!MaMXUtHUxa1yubdBaCdqw==  to report this email as spam.

RE: Unexpected Externals behaviour in working copy

Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi

I haven't had a reply to this question of mine yet. So I would like to rephrase it:

Is it true that if I delete an external relating to a folder or file then svn will not automatically delete that folder/file from my local working copy?

This seems to be related to Subversion issue #3351 (although that issue only relates to file externals, not folder externals).

It is seems that a fresh check out is required. Or is it ok to delete the 'external' folder/file in my wc using an operating system delete operation?

Best regards

David

________________________________________
From: David Aldrich [David.Aldrich@eu.nec.com]
Sent: 11 March 2010 16:11
To: users@subversion.apache.org
Subject: Unexpected Externals behaviour in working copy

Hi

I have a question about externals. I tried the following scenario in my working copy:

1) Add an external definition to directory A, specifying subdirectory B
2) Commit directory A
3) Update directory A

I then see A/B populated

Then:

4) Edit external definition to directory A, specifying subdirectory C
5) Commit directory A
6) Update directory A

I then see A/C populated, but directory A/B remains in the wc.

If I checkout a new working copy, it shows A/C but not A/B, as expected.

So, in short, changing an external definition on a directory seems not to remove the previous external content from the committer's working copy.

I hope this makes sense. Please will someone explain?

Best regards

David



 Click https://www.mailcontrol.com/sr/nypLE7lZxS7TndxI!oX7UvIItv2OGGpTAw!IKZCqldsHAq!cPr+aidCSu5mXugUL!MaMXUtHUxa1yubdBaCdqw==  to report this email as spam.