More fun w/ working copy on SMB share

[Markus S <yo...@hispeed.ch>]

Hi,

recently, I reported here that adding empty files to repositories (even 
if they are deleted again) in the inability to interact with a working 
copy on a SMB share accessed from Mac OS X 10.4.x (see my post from 8 
June: Commit failed: 'Can't copy ... Input/output error').

I now had trouble with a word file. It worked fine with my local 
working copy until I checked it out (via update) to a working copy on a 
SMB share. There, the update would fail (with "Can't copy ..."). 
Subsequent attempts to do anything with the working copy would fail 
with "The working copy is locked". I had to delete the working copy and 
check it out again to get it working.

Deleting the word file from the repository and adding the same file 
under a different name produced the same results. Resaving the file in 
word under a different name and adding it again worked however.

I could imaging that resource forks might play a role but why resaving 
it under a different name fixes it, I have no idea.

Markus



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

Re: More fun w/ working copy on SMB share

[Matt Sickler <cr...@gmail.com>]

Just going to point out here that generally, accessing working copies
or repositories over any kind of network share generally doesnt work.
Yes it does in some specialized situations, but they are a bit
difficult to set up.

On 6/21/07, Markus S <yo...@hispeed.ch> wrote:
> Hi,
>
> recently, I reported here that adding empty files to repositories (even
> if they are deleted again) in the inability to interact with a working
> copy on a SMB share accessed from Mac OS X 10.4.x (see my post from 8
> June: Commit failed: 'Can't copy ... Input/output error').
>
> I now had trouble with a word file. It worked fine with my local
> working copy until I checked it out (via update) to a working copy on a
> SMB share. There, the update would fail (with "Can't copy ...").
> Subsequent attempts to do anything with the working copy would fail
> with "The working copy is locked". I had to delete the working copy and
> check it out again to get it working.
>
> Deleting the word file from the repository and adding the same file
> under a different name produced the same results. Resaving the file in
> word under a different name and adding it again worked however.
>
> I could imaging that resource forks might play a role but why resaving
> it under a different name fixes it, I have no idea.
>
> Markus
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

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

Re: More fun w/ working copy on SMB share

[Jeremy Wilkins <je...@ibexinternet.co.uk>]

I think subversion on mac os tries to do a file rename or some other  
action within the .svn files which smb doesn't support, I suspect  
subversion on linux using smbfs has the same issue (though possibly  
not with cifs and a samba server with unix extensions). Subversion on  
windows does the rename (or which ever action it is) differently,  
since the local file systems have the same issue, hence are able to  
work on smb shares.
---
Jeremy Wilkins

On 21 Jun 2007, at 23:17, Ryan Schmidt wrote:

> On Jun 21, 2007, at 09:03, Markus S wrote:
>
>> recently, I reported here that adding empty files to repositories  
>> (even if they are deleted again) in the inability to interact with  
>> a working copy on a SMB share accessed from Mac OS X 10.4.x (see  
>> my post from 8 June: Commit failed: 'Can't copy ... Input/output  
>> error').
>>
>> I now had trouble with a word file. It worked fine with my local  
>> working copy until I checked it out (via update) to a working copy  
>> on a SMB share. There, the update would fail (with "Can't  
>> copy ..."). Subsequent attempts to do anything with the working  
>> copy would fail with "The working copy is locked". I had to delete  
>> the working copy and check it out again to get it working.
>>
>> Deleting the word file from the repository and adding the same  
>> file under a different name produced the same results. Resaving  
>> the file in word under a different name and adding it again worked  
>> however.
>>
>> I could imaging that resource forks might play a role but why  
>> resaving it under a different name fixes it, I have no idea.
>
> Resource forks are unlikely to have anything to do with it, since  
> Subversion will not see or store them.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

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

Re: More fun w/ working copy on SMB share

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 21, 2007, at 09:03, Markus S wrote:

> recently, I reported here that adding empty files to repositories  
> (even if they are deleted again) in the inability to interact with  
> a working copy on a SMB share accessed from Mac OS X 10.4.x (see my  
> post from 8 June: Commit failed: 'Can't copy ... Input/output error').
>
> I now had trouble with a word file. It worked fine with my local  
> working copy until I checked it out (via update) to a working copy  
> on a SMB share. There, the update would fail (with "Can't  
> copy ..."). Subsequent attempts to do anything with the working  
> copy would fail with "The working copy is locked". I had to delete  
> the working copy and check it out again to get it working.
>
> Deleting the word file from the repository and adding the same file  
> under a different name produced the same results. Resaving the file  
> in word under a different name and adding it again worked however.
>
> I could imaging that resource forks might play a role but why  
> resaving it under a different name fixes it, I have no idea.

Resource forks are unlikely to have anything to do with it, since  
Subversion will not see or store them.



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