Cleaning Up After SVN Externals, the Bug and the Fix.
SVN externals are a convenient way to organize your subversion repository. They serve roughly the same purpose as symbolic links on a Linux filesystem. Unfortunately, there seems to be a bug that may give you a good deal of headache if you later decide to replace an svn external with an actual folder (a drop). This quick blog post describes the problem and the solution.
Problem Description
Let’s say we had created an external by running:
> svn propedit svn:externals .
and typing in the editor:
ourcomponent https://svn.example.com/someproject/trunk/subfolder/versions/v1.2
Later on, we may find a need to replace the external with an actual local copy. This is often needed if you need to start managing the component as an SVN Vendor Branch and have to turn the external into a local “drop”. To do so, you’d naturally edit the svn:externals property again (much like you did above) and empty-out the existing external. After which you’d commit the change and double-check that repo and workplace are fine. They will be fine, both your local workspace and the repository. Furthermore, anybody doing a clean checkout will also be fine, however your fellow developers, who already had a checked-out workspace version, will get the following nasty error, next time they try to update:
svn: Failed to add directory 'ourcomponent': object of the same name already exists
One Solution
Following is the solution that worked for me in cleaning corrupted workspaces, without loosing any data. I admit some of the steps are counter-intuitive and maybe even illogical, but, well, it works. Use it at your own risk:
> svn propedit svn:externals .
and delete the line that contains external.
> svn commit -m "cleaning up after svn bug" -N .
this step will actually give you an error stating that your workspace is out of date. You still need this step, though.
> svn status
> rm -rf ourcomponent
> svn update
Your workspace should be fine after the final step.
Comments
Post new comment