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.schoen...@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...
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.
Re: Subversion 1.6.18 released
Daniel Shahaf wrote on Sat, Apr 14, 2012 at 18:28:05 +0300: > Stefan Sperling wrote on Sat, Apr 14, 2012 at 17:00:19 +0200: > > On Sat, Apr 14, 2012 at 10:05:36AM -0400, Nico Kadel-Garcia wrote: > > > It's cool. I've seen projects fork and keep the same name before, and it > > > wasn't pretty. > > > > Just to be clear: It's not a fork. It's the same project under a new > > umbrella. > > > > > The COPYING file also mentions checking > > > http://subversion.tigris.org/license-1.html, which now points to > > > http://svn.apache.org/repos/asf/subversion/trunk/LICENSE, which an ASL 2.0 > > > license. Any chance of getting the COPYING file updated to reflect the > > > newer license? > > > > Hmm. That looks wrong. I think license-1.html should display the > > old licence and point out that newer releases use a difference licence. > > +1. (license-1.html is what our old releases refer to, so we can't > change it. Typical of svn devs to embed a version number into > a URL..) Can someone apply this to tigris please? [[[ * www/license-1.html: Link to the historic v1 license. Found by: Nico Kadel-Garcia ]]] [[[ Index: license-1.html === --- license-1.html (revision 120) +++ license-1.html (working copy) @@ -8,6 +8,8 @@ This information has been moved to http://svn.apache.org/repos/asf/subversion/trunk/LICENSE"; ->http://svn.apache.org/repos/asf/subversion/trunk/LICENSE +>http://svn.apache.org/repos/asf/subversion/trunk/LICENSE. +http://svn.apache.org/repos/asf/subversion/tags/1.6.0/www/license-1.html"; +>The historic contents of this page is also available. ]]]
Re: Subversion 1.6.18 released
On Tue, Apr 24, 2012 at 01:30:56PM +0300, Daniel Shahaf wrote: > Can someone apply this to tigris please? Thanks, done. > > [[[ > * www/license-1.html: Link to the historic v1 license. > > Found by: Nico Kadel-Garcia > ]]] > > [[[ > Index: license-1.html > === > --- license-1.html(revision 120) > +++ license-1.html(working copy) > @@ -8,6 +8,8 @@ > > This information has been moved to > http://svn.apache.org/repos/asf/subversion/trunk/LICENSE"; > ->http://svn.apache.org/repos/asf/subversion/trunk/LICENSE > +>http://svn.apache.org/repos/asf/subversion/trunk/LICENSE. > + href="http://svn.apache.org/repos/asf/subversion/tags/1.6.0/www/license-1.html"; > +>The historic contents of this page is also available. > > > > ]]]
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
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.schoen...@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: Trouble with shared object so file with svn_load_dirs.pl
Le 23 avril 2012 17:46, Yves Martin a écrit : > Everything seems to be OK, except for one file - a Unix binary .so > executable file - the script detects it as added whereas it is already > present in the branch working copy and it has not changed at all. > > As a result, the "svn add" operation just fails with: > svn: warning: W150002: '/path/to/current/myFileWithSomeCapLetters.so' > is already under version control > svn: E29: Could not add all targets because some targets are > already versioned > svn: E29: Illegal target for the requested operation > Press return to quit and clean up svn working directory: > How to diagnose what is wrong ? Hello, I browse the Perl source and discover that the "global ignores" option defaults to the variable from .subversion/config and it contains the "*.so" pattern ! As this ignore list is used when scanning the source / working copy, the file from the "vendor release" is detected as added. What I find strange is why the global ignore list is not used to scan the "vendor release" too. So here is the solution: I have to define manually the "global_ignores" option on command line. -- Yves Martin
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
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.schoen...@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...
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...
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.schoen...@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...
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.
Vendor branch with customization, to be used in multiple projects
Hello, I hope this is appropriate for the mailing list—and I apologize if it isn't—but I have a repository design issue that I haven't been able to find discussed elsewhere and was wondering if anyone would be willing to offer their thoughts. I'm using a single repository to hold multiple projects. Each of these projects uses third party code from a particular vendor. They may use different versions of that code, but this is handled well using vendor branches as described in the SVN book, with a slight twist to accomodate multiple projects. - / (repository root) - projects/ - ProjectA/ - VendorA/ (svn:externals "^/vendors/VendorA/1.1/") - ProjectB/ - VendorA/ (svn:externals "^/vendors/VendorA/1.0/") - vendors/ - VendorA/ - 1.0/ - 1.1/ - current/ I've so far had no need for project-specific customizations, which is why I'm using svn:externals. Now, I also maintain a couple of local bug fixes for VendorA's code. Since they're bug fixes, they should be available to all projects. The part I'm struggling with is just figuring out the cleanest way of handling this situation. My first thought was to load up the initial drop, patch it, and tag it in some way indicating that it has been customized. Something like this: - vendors/ - VendorA/ - 1.0-custom1/ - current/ Then I realized that svn_load_dirs (or Ubuntu's equivalent, at least: svn-load) doesn't actually merge changes; it's just an import. That means any customizations in "current" would be overwritten and I would have to reapply my patches for each new vendor drop. Another option is to keep the customizations separate: - vendors/ - VendorA/ - 1.0/ - current/ - vendors-custom/ - VendorA/ - 1.0-custom1/ - current/ Maybe a combination of the two: - vendors/ - VendorA/ - 1.0/ - 1.0-custom1/ - current/ - current-custom/ But with the extra merging and tagging that would be needed to keep this custom branch up-to-date, it might actually be easier to just re-patch each new vendor drop. Any thoughts, advice, and suggestions would be very welcome. Thanks, Ryan
Re: Can't commit contents of symbolically linked files with Subversion 1.7.2...
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.schoen...@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: Vendor branch with customization, to be used in multiple projects
On Apr 24, 2012, at 11:25, Ryan Lange wrote: > Hello, > > I hope this is appropriate for the mailing list—and I apologize if it > isn't—but I have a repository design issue that I haven't been able to > find discussed elsewhere and was wondering if anyone would be willing > to offer their thoughts. > > I'm using a single repository to hold multiple projects. Each of these > projects uses third party code from a particular vendor. They may use > different versions of that code, but this is handled well using vendor > branches as described in the SVN book, with a slight twist to > accomodate multiple projects. > >- / (repository root) >- projects/ >- ProjectA/ >- VendorA/ (svn:externals "^/vendors/VendorA/1.1/") >- ProjectB/ >- VendorA/ (svn:externals "^/vendors/VendorA/1.0/") >- vendors/ >- VendorA/ >- 1.0/ >- 1.1/ >- current/ > > I've so far had no need for project-specific customizations, which is > why I'm using svn:externals. Now, I also maintain a couple of local > bug fixes for VendorA's code. Since they're bug fixes, they should be > available to all projects. The part I'm struggling with is just > figuring out the cleanest way of handling this situation. My first > thought was to load up the initial drop, patch it, and tag it in some > way indicating that it has been customized. Something like this: > >- vendors/ >- VendorA/ >- 1.0-custom1/ >- current/ > > Then I realized that svn_load_dirs (or Ubuntu's equivalent, at least: > svn-load) doesn't actually merge changes; it's just an import. That > means any customizations in "current" would be overwritten and I would > have to reapply my patches for each new vendor drop. > > Another option is to keep the customizations separate: > >- vendors/ >- VendorA/ >- 1.0/ >- current/ >- vendors-custom/ >- VendorA/ >- 1.0-custom1/ >- current/ > > Maybe a combination of the two: > >- vendors/ >- VendorA/ >- 1.0/ >- 1.0-custom1/ >- current/ >- current-custom/ > > But with the extra merging and tagging that would be needed to keep > this custom branch up-to-date, it might actually be easier to just > re-patch each new vendor drop. > > Any thoughts, advice, and suggestions would be very welcome. The convention is that /vendor should contain *only* vendor code, with no modifications. If you want to modify vendor code, copy it elsewhere in your repository and make your modifications (bug fixes, etc.) there. Then, in the projects where you want to use that modified vendor code, you can set an external to that new location. When a new vendor version is released, you "svn_load_dirs.pl" it in /vendor as usual, then "svn merge" it into your bugfixed/enhanced copy, then update the externals that reference it.
Re: Vendor branch with customization, to be used in multiple projects
On Tue, Apr 24, 2012 at 12:25:22PM -0400, Ryan Lange wrote: > Hello, > > I hope this is appropriate for the mailing list—and I apologize if it > isn't—but I have a repository design issue that I haven't been able to > find discussed elsewhere and was wondering if anyone would be willing > to offer their thoughts. > > I'm using a single repository to hold multiple projects. Each of these > projects uses third party code from a particular vendor. They may use > different versions of that code, but this is handled well using vendor > branches as described in the SVN book, with a slight twist to > accomodate multiple projects. > > - / (repository root) > - projects/ > - ProjectA/ > - VendorA/ (svn:externals "^/vendors/VendorA/1.1/") > - ProjectB/ > - VendorA/ (svn:externals "^/vendors/VendorA/1.0/") > - vendors/ > - VendorA/ > - 1.0/ > - 1.1/ > - current/ > > I've so far had no need for project-specific customizations, which is > why I'm using svn:externals. Now, I also maintain a couple of local > bug fixes for VendorA's code. Since they're bug fixes, they should be > available to all projects. The part I'm struggling with is just > figuring out the cleanest way of handling this situation. My first > thought was to load up the initial drop, patch it, and tag it in some > way indicating that it has been customized. Something like this: > > - vendors/ > - VendorA/ > - 1.0-custom1/ > - current/ > > Then I realized that svn_load_dirs (or Ubuntu's equivalent, at least: > svn-load) doesn't actually merge changes; it's just an import. That > means any customizations in "current" would be overwritten and I would > have to reapply my patches for each new vendor drop. > > Another option is to keep the customizations separate: > > - vendors/ > - VendorA/ > - 1.0/ > - current/ > - vendors-custom/ > - VendorA/ > - 1.0-custom1/ > - current/ > > Maybe a combination of the two: > > - vendors/ > - VendorA/ > - 1.0/ > - 1.0-custom1/ > - current/ > - current-custom/ > > But with the extra merging and tagging that would be needed to keep > this custom branch up-to-date, it might actually be easier to just > re-patch each new vendor drop. > > Any thoughts, advice, and suggestions would be very welcome. > > Thanks, > Ryan The extra merging and tagging buys you one very important thing: It allows you to cleanly see the difference between the vendor's version of the code and your own simply by comparing two URLs. If you commit your own changes directly on the vendor branch you don't have clean separation of histories of their and your own change and telling apart changes coming from either side becomes a bit messy. It is not actually that complicated once you get used to it. The usual approach would be to leave the 'vendor' branch unmodified, and create a branch off this 'vendor' branch which you modify freely. This modified branch can be used in your own projects (e.g. via an external, as you do now). Using svn_load_dirs you keep loading unmodified vendor drops on the unmodified branch whenever you want to catch up with new vendor releases. Visualising this in a graph where time flows from left to right and each line represents a branch it looks like this: your commits go on this branch /custom/VendorA +--- / / copy / /vendors/VendorA ---+ initial drop new vendor drops go here (via svn_load_dirs) imported here Now, each time you import a new drop, you can merge the incoming changes into your custom branch, on top of your own local changes: /custom/VendorA +--+- / / / copy / merge r10-r200 vendor->custom / / /vendors/VendorA -+--r200 r10 new vendor drop X imported in r200 The commands to run this merge would be: svn checkout http://svn.example.com/svn/custom/VendorA cd VendorA svn merge ^/vendors/VendorA # fix any conflicts svn commit -m "merged vendor drop X with custom changes" You don't need to specify revision numbers because merge-tracking takes care of that for you.
