Re: "ghost" files in repository - solved

Hello,

> Physically removing the parent directory of your working copy with some OS
> tool and freshly updating it should be sufficient. Do you have any ideas which
> actions/SVN operations might have introduced this working copy mismatch?

My coworker says that he tried to rearrange some files directly in his
working copy rather than through SmartSVN, but he can't remember exactly
what steps led to the problem.

Unfortunately, starting with a new working copy didn't help. I also tried
looking inside an svndump file, but the "ghost" files didn't have nodes
there.

After digging further, I found out that these files had been deleted, but
that the repository was still tracking their locks. The locks were causing
the files to appear in SmartSVN as "repository-only" and were preventing us
from removing their parent directories, but we couldn't remove the files
themselves because they didn't exist.

The solution was to break the locks on the files. I couldn't find a way to
do this in SmartSVN, but I did it from the command line with commands like
this:

svn unlock --force
server.domain.name/path/to/file/badfile.html">svn+ssh://usernameserver.domain.name/path/to/file/badfile.html

Once I did that on a file, its ghost disappeared from SmartSVN and all was
well.

I don't know if this has anything to do with SmartSVN, but I figured I'd
post the solution in case it helps anyone.

Cheers,
-Arlo

_______________________________

Arlo Leach
773.769.6106
http://arlomedia.com

Make friends with your computer
http://compyschool.com

Messages in this topic (3) Reply (via web post) | Start a new topic

.

Hello Arlo,

> After digging further, I found out that these files had been deleted, but
> that the repository was still tracking their locks.

This should probably not happen. Is this somehow reproducible for you? Which
SVN server version are you using?

> The solution was to break the locks on the files. I couldn't find a way to
> do this in SmartSVN, but I did it from the command line with commands like
>; this

SmartSVN supports "--force" option for unlocking. Did you try this?

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com

Arlo Leach < arlo%40arlomedia.com">arloarlomedia.com> wrote:

> Hello,
&gt;
> > Physically removing the parent directory of your working copy with some OS
> > tool and freshly updating it should be sufficient. Do you have any ideas which
&gt; > actions/SVN operations might have introduced this working copy mismatch?
>
> My coworker says that he tried to rearrange some files directly in his
> working copy rather than through SmartSVN, but he can't remember exactly
> what steps led to the problem.
>
> Unfortunately, starting with a new working copy didn't help. I also tried
&gt; looking inside an svndump file, but the "ghost" files didn't have nodes
&gt; there.
&gt;
> After digging further, I found out that these files had been deleted, but
> that the repository was still tracking their locks. The locks were causing
> the files to appear in SmartSVN as "repository-only" and were preventing us
> from removing their parent directories, but we couldn't remove the files
&gt; themselves because they didn't exist.
&gt;
> The solution was to break the locks on the files. I couldn't find a way to
> do this in SmartSVN, but I did it from the command line with commands like
>; this:
&gt;
> svn unlock --force
> server.domain.name/path/to/file/badfile.html">svn+ssh://usernameserver.domain.name/path/to/file/badfile.html
&gt;
> Once I did that on a file, its ghost disappeared from SmartSVN and all was
> well.
&gt;
> I don't know if this has anything to do with SmartSVN, but I figured I'd
> post the solution in case it helps anyone.
>
> Cheers,
> -Arlo
&gt;
> _______________________________
>
> Arlo Leach
&gt; 773.769.6106
> http://arlomedia.com
>
> Make friends with your computer
> http://compyschool.com
>
>
>
>
>
>
> Yahoo! Groups Links
&gt;
>
>
>
>

Messages in this topic (4) Reply (via web post) | Start a new topic

.