You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2012/04/24 11:55:47 UTC
Can't commit contents of symbolically linked files with Subversion 1.7.2...
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.
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.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Stefan Sperling,
am Dienstag, 24. April 2012 um 18:24 schrieben Sie:
> is there ever more than one customer
> branch involved in your case?
No, as we only update other customers if necessary, then the get
merged and on special bugs we would behave like described before.
> It seems better to track the fix being merged
> to each customer-specific branch ([...]), rather than having two independent
> non-merge commits that happen to fix the same problem.
You're right and with a subversion server with merge tracking, we
currently use 1.4 as a server, your process is clearly the better one.
Thanks for the clarifications.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't commit contents of symbolically linked files with
Subversion 1.7.2...
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Apr 24, 2012 at 06:06:52PM +0200, Thorsten Schöning wrote:
> I don't think so, I need the tag to be as it is now, because that's
> what get's deployed to the production servers and it really consists
> all a web application for a customer needs and I want it versioned in
> one combined folder. Because former versions of the svn client seemed
> to ignore my file replacement to a symlink we were able to implement
> this fast bugfix process: Test the customer templates and most of the
> configuration with the symlinked programs from trunk, fix the bug in
> trink while testing it with the customer installation and if it was
> fixed just commit on the development server once for trunk and once
> for the customer folder. Only th latter brekas now so it seems I just
> have to adjust my workflow to merge the commits from trunk to the
> customer in a separate step and folder without the symlinks.
Yes. I would say that a merge is the correct thing to do here anyway
in terms of process policy. It seems better to track the fix being merged
to each customer-specific branch (is there ever more than one customer
branch involved in your case?), rather than having two independent
non-merge commits that happen to fix the same problem.
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Stefan Sperling,
am Dienstag, 24. April 2012 um 17:48 schrieben Sie:
> Ah, so you are obstructing a versioned file with a symlink?
Yes.
> That's why 'svn status' shows the '~' symbol which means "obstructed".
Thanks.
> I think you should somehow rearrange
> your project so you don't have to do that. Perhaps you can move the
> versioned file to a different location?
I don't think so, I need the tag to be as it is now, because that's
what get's deployed to the production servers and it really consists
all a web application for a customer needs and I want it versioned in
one combined folder. Because former versions of the svn client seemed
to ignore my file replacement to a symlink we were able to implement
this fast bugfix process: Test the customer templates and most of the
configuration with the symlinked programs from trunk, fix the bug in
trink while testing it with the customer installation and if it was
fixed just commit on the development server once for trunk and once
for the customer folder. Only th latter brekas now so it seems I just
have to adjust my workflow to merge the commits from trunk to the
customer in a separate step and folder without the symlinks.
> Maybe externals will help?
Wouldn't know how, as I want the tags unchanged, and only wnated to
replace the binaries of the web application for the fast bugfix way
with the contents of the trunk, keeping all themes etc. of the
customer. Symlinks on filesystem level were a good way to trick
Subversion and achieve this.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't commit contents of symbolically linked files with
Subversion 1.7.2...
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Apr 24, 2012 at 05:38:20PM +0200, Thorsten Schöning wrote:
> No, each customer folder was a somewhen branched copy of the reference
> folder and does have all of it's own versioned files and folders. The
> links were just created on the filesystem level by deleting the
> versioned file and replacing it with a ln -s to toe same file in the
> reference folder. No svn operations involved, only filesystem and in
> earlier versions of the svn client this was fully transparent.
> Subversion didn't recognized changed file types, from native file to
> symbolic link, but only saw changes in file contents itself, if the
> referenced file got changed.
Ah, so you are obstructing a versioned file with a symlink?
That's why 'svn status' shows the '~' symbol which means "obstructed".
It seems that the smarter handling of symlinks in 1.7 is what
breaks your current workflow. I don't think Subversion ever
intentionally ignored the fact that you are replacing a versioned
file with an unversioned symlink. I think you should somehow rearrange
your project so you don't have to do that. Perhaps you can move the
versioned file to a different location?
> I can't use versioned symlinks at all because the reference folder is
> trunk, not present on the production folders, I have Windows clients
> which needs the customer-specific files and where the symbolic links
> won't work etc.
Maybe externals will help?
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Thorsten Schöning,
am Dienstag, 24. April 2012 um 17:38 schrieben Sie:
> No, each customer folder was a somewhen branched copy of the reference
> folder and does have all of it's own versioned files and folders. The
> links were just created on the filesystem level by deleting the
> versioned file and replacing it with a ln -s to toe same file in the
> reference folder. No svn operations involved, only filesystem and in
> earlier versions of the svn client this was fully transparent.
> Subversion didn't recognized changed file types, from native file to
> symbolic link, but only saw changes in file contents itself, if the
> referenced file got changed.
One more thing is that each of the folders is it's own working copy
independent from the others, besides the symbolic links to some files
of the working copy of the trunk-folder. They are all somewhere in the
same repo, as trunk and tags or branches, but each folder on the
development server has been checked out independantly from the other
folders and the root folder of all of them is not a working copy at
all.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Stefan Sperling,
am Dienstag, 24. April 2012 um 12:19 schrieben Sie:
> you mention that you're using 1.7.2.
> Have you tried 1.7.4?
I upgraded and there were no changes in my described behaviour.
Subversion seems to recognized the change of the file to a symbolic
link itself, which seemed to be ignored in earlier versions of my
client.
> Did you add the symlinks to version control?
No, each customer folder was a somewhen branched copy of the reference
folder and does have all of it's own versioned files and folders. The
links were just created on the filesystem level by deleting the
versioned file and replacing it with a ln -s to toe same file in the
reference folder. No svn operations involved, only filesystem and in
earlier versions of the svn client this was fully transparent.
Subversion didn't recognized changed file types, from native file to
symbolic link, but only saw changes in file contents itself, if the
referenced file got changed.
> 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.
I can't use versioned symlinks at all because the reference folder is
trunk, not present on the production folders, I have Windows clients
which needs the customer-specific files and where the symbolic links
won't work etc.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't commit contents of symbolically linked files with
Subversion 1.7.2...
Posted by Stefan Sperling <st...@elego.de>.
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.