On Tue, Apr 24, 2012 at 11:55:47AM +0200, Thorsten Schöning wrote:
> Hello,
>
> on one of our development servers we have a special setup with folders
> for different customers, one reference folder with codebase of a web
> application and the contents of the customer folders are linked
> symbolically to the reference folder. The reason was to be able to
> test customers themes etc. with current code base by beeing able to
> commit little changes to files without the need to explicitly merge.
> This setup worked pretty fine in Subversion 1.6 and before, but
> doesn't seem to work now. When I do a svn status in a customer folder
> every linked file is shown with a ~ and not just those files which
> contents were changed against the own base of the customer folder.
> Commits are not possible because of error E145001, saying something
> about the special status of the file has changed unexpectadly. The
> error message is presented in german language only.
Hi Thorsten,
you mention that you're using 1.7.2.
Have you tried 1.7.4? Some bugs with symlinks were fixed:
* fix spurious conflict when merging deleted symbolic link (issue #4052)
* fix regressions with symlinks pointing at externals (issue #4102)
I think the second fix might be relevant. It changed the way svn
resolves symlinks while locating working copy roots. This might affect
the problem you describe below.
> Is there any possibility to be able to get the old behaviour back? I
> don't want Subversion in this case to recognize that a file was
> replaced with a symbolic link, but use the link fully transparent and
> only consider the contents of a file.
>
> An example of my folders:
>
> reference_folder
> - fileA
> - fileB
> customer1
> - fileA -> reference_folder/fileA
> - fileB -> reference_folder/fileB
>
> The links were created with link -s. If I change
> reference_folder/fileA and visit customer1/fileA in vi, I see the
> changed contents, but svn status customer1/file A prints ~ and the
> file can't be committed, too.
Did you add the symlinks to version control?
It sounds like perhaps your case would be better handled by unversioned
symlinks. Please experiment with versioned/unversioned symlinks in 1.7.4
and check if you can get the desired behaviour.
