expanding custom keywords in dump
I’m trying to automate the real-time importing (mirroring) of the FreeBSD SVN tree into a Perforce tree. This is not for FreeBSD development but to allow integration of two projects, both based on FreeBSD (and leaving p4 is not an option :-( ). Perforce have a tool that takes a SVN dump and converts it into perforce transactions in a very 1:1 way (p4import-svn). Unfortunately the one thing that fails is that custom keywords are not expanded. This doesn’t seem much but in the merged project there is no way to see what revision of file was imported from the FreeBSD repository, as the “$FreeBSD$” keyword is left unexpanded on export. This also means that files that are moved across to Perforce will always have diffs with files taken from the DVD images as they have the keyword expanded. One project started with a DVD image so the large project i’m merging with has a lot of freeBSD files taken from that DVD, and thus there are a lot of false merge conflicts. Is there any way that the subversion dump routine can be configured to allow expansion of these keywords? In this usage, the dump is effectively playing the part of the client. Having it expand the keywords would allow the expanded version to be imported into Perforce which would then contain files that would match what is exported on the DVDs. Would this even be a useful thing for exporting the a project repo to another SVN based repo so that such keywords would be “frozen” in place? Regards, Julian
Re: expanding custom keywords in dump
On 31.01.2014 11:07, Julian Elischer wrote: > I’m trying to automate the real-time importing (mirroring) of the > FreeBSD SVN tree into a Perforce tree. This is not for FreeBSD > development but to allow integration of two projects, both based on > FreeBSD (and leaving p4 is not an option :-( ). > Perforce have a tool that takes a SVN dump and converts it into > perforce transactions in a very 1:1 way (p4import-svn). > > Unfortunately the one thing that fails is that custom keywords are not > expanded. This doesn’t seem much but in the merged project there is no > way to see what revision of file was imported from the FreeBSD > repository, as the “$FreeBSD$” keyword is left unexpanded on export. > This also means that files that are moved across to Perforce will > always have diffs with files taken from the DVD images as they have > the keyword expanded. One project started with a DVD image so the > large project i’m merging with has a lot of freeBSD files taken from > that DVD, and thus there are a lot of false merge conflicts. > > Is there any way that the subversion dump routine can be configured to > allow expansion of these keywords? In this usage, the dump is > effectively playing the part of the client. Having it expand the > keywords would allow the expanded version to be imported into Perforce > which would then contain files that would match what is exported on > the DVDs. > Would this even be a useful thing for exporting the a project repo to > another SVN based repo so that such keywords would be “frozen” in place? There's currently no way to tell either 'svnadmin dump' or 'svnrdump dump' to expand keywords. These tools were designed to create a backup of the repository, not the working copy; and since the repository stores keywords unexpanded, there was no reason to add such a feature. Note that expanding keywords in the dump would make no sense for Subversion in any case; since the svn:keywords properties are also part of the dump, a client would expect them to be unexpanded in the repository and would report spurious diffs in the keyword expansion. Expanding keywords might, you point out, be useful for migrating to another VCS, and adding such an feature is definitely an option. Patches are always welcome. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: expanding custom keywords in dump
Guten Tag Julian Elischer, am Freitag, 31. Januar 2014 um 11:07 schrieben Sie: > [...]“$FreeBSD$” keyword is left unexpanded on export. This doesn't seem to be a keyword which svn clients expand by default, therefore you would have two building lots. http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html 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...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Vendor Branches from Foreign Repositories: svn: E200009: Can't set 'svn:eol-style'
Hello, I'm trying to import a vendor branch from a foreign repository by: d:\foo>svn copy http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0 Boost svn starts copying, but aborts with E29: Can't set 'svn:eol-style': --- Copying from foreign repository URL 'http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0': : : A Boost\tools\quickbook\test\html\images svn: E29: Can't set 'svn:eol-style': file 'D:\foo\Boost\tools\quickbook\test\html\images\open_clipart_library_logo.svg ' has binary mime type property Since I have no control over the foreign repository I can't fix this issue and am now stuck and unable to complete the import. I think SVN should either skip the properties for this file and place a warning or mark it as a conflict but continue to import instead of abort. Can anybody add this to the issue tracker? Is there a workaround to solve this? Regards, Uwe smime.p7s Description: S/MIME cryptographic signature
RE: Disjoint working copy
> Is there a way to get full status information for a disjoint working copy > without performing "svn st" on each sub working copies? A workaround on Linux with svn client 1.7 or newer is to use a command similar to: find . -type d -name "\.svn" | sed 's/\.svn$//' | xargs svn st Then at least I get a complete status, but is there some better way to get "svn st to show the complete status for the disjoint working copy? That is instead of reporting: ? wc/mod1 in the example. It would be nice if svn did understand that wc/mod1 is actually a new working copy (it could just look at the wc/mod1/.svn folder). /Atle
Re: Disjoint working copy
On Fri, Jan 31, 2014 at 9:18 AM, Ræstad Atle Eivind wrote: >> Is there a way to get full status information for a disjoint working copy >> without performing "svn st" on each sub working copies? > > A workaround on Linux with svn client 1.7 or newer is to use a command > similar to: > find . -type d -name "\.svn" | sed 's/\.svn$//' | xargs svn st > Is that really easier than setting an external property? -- Les Mikesell lesmikes...@gmail.com
Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi - I have been trying to pin down the cause of an issue my users are seeing when using SVN. It's actually a Windows Server 2008 R2 (64 bit) Bitnami-Redmine stack of SVN, but I've tried to scrape it back to the most basic levels during debugging, to hopefully omit any Bitnami-related issues. I have seen this occur when the underlying SVN install is 1.8.3 and 1.8.4 I have performed the following actions (on the server itself, sing the bitnami cmd prompt to ensure all environment variables for SVN should be as expected) :: Create a new repository. No options or extras - no hooks. svnadmin create f:\svn_repository\Testrepo :: Check the empty repo out to my local disk (on the SVN Server) - obviously I've masked the real address here svn co https://xx.com/svn/Testrepo c:\dev\Testrepo :: created a simple text file manually under windows - NewDoc.txt with a few bytes of text in it so it's not empty :: Made SVN aware of the file by adding it svn add c:\dev\Testrepo\NewDoc.txt :: Committed the file into the repository svn ci c:\dev\Testrepo -m "test commit" :: Attempted to lock the working file svn lock c:\dev\Testrepo\NewDoc.txt Response: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL svn: E200035: Additional errors: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL I've been digging around on this for a while - seen one or two examples of people seeing this, but not seen any solutions as-of-yet. I couldn't find any trace of a bug raised either (Hopefully I've not missed one!) I've first seen this in a Bitnami 2.3.2.1 install, and to try to make sure it's not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: Same result. I have tried a totally standalone collabnet svn server install of 1.8.5 on a separate machine, and the locks on that are working. I then put 1.8.5 onto the server where we're seeing the problem and once again the same problem occurred. So this seems to be an issue occurring as a result of the configuration setup we have on that server. We do make use of an access file on that server, so my next test was to disable the access file setup and retry. This worked exactly as expected (by using a checkout using the local file system), responding that the file had been locked So, it would seem that this issue is related to the use of the following httpd.conf settings: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.s And/or serving the files over https And the related settings pointing to the relevant access authority file. Can anyone advise or assist with this? Has anyone else seen this issue? I'm starting to run out of ideas of how to further pinpoint this at the moment... Many thanks for any advice or assistance! Regards - Steve This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and agents. A division of Rapp Limited. Registered Office: 1 Riverside, Manbre Road, London W6 9WA Registered in England no: 1581935 --- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.co.uk ---
Re: Vendor Branches from Foreign Repositories: svn: E200009: Can't set 'svn:eol-style'
On 1/31/14, 5:49 AM, Uwe Tropp wrote: > I'm trying to import a vendor branch from a foreign repository by: > > d:\foo>svn copy http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0 > Boost > > svn starts copying, but aborts with E29: Can't set 'svn:eol-style': > > --- Copying from foreign repository URL > 'http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0': > : > : > A Boost\tools\quickbook\test\html\images > svn: E29: Can't set 'svn:eol-style': file > 'D:\foo\Boost\tools\quickbook\test\html\images\open_clipart_library_logo.svg > ' has binary mime type property > > Since I have no control over the foreign repository I can't fix this issue > and am now stuck and unable to complete the import. > I think SVN should either skip the properties for this file and place a > warning or mark it as a conflict but continue to import instead of abort. > > Can anybody add this to the issue tracker? > > Is there a workaround to solve this? I agree, this isn't very useful as it stands. Fixed on trunk with: http://svn.apache.org/r1563361 Don't think we'll backport this to 1.8 since I ended up adding an API. We probably could though with some effort of switch the foreign copy from using the svn_wc_add_from_disk2() into using the other functions that can do all the same things, just can't do them all at once and ultimately end up using svn_wc_prop_set4() which already has the argument to skip the property canonicalization. You could workaround this locally by modifying subversion/libsvn_wc/adm_ops.c to change the skip_some_checks argument to the svn_wc__canonicalize_props() call in svn_wc_add_from_disk2(). That's at line 1016 in the current 1.8.x branch. However, that will disable those checks for all adds (including those done via svn add, svn merge, and svn patch) which I wouldn't recommend for daily usage. But that sort of patch might get you past this issue temporarily.
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
On 1/31/14, 1:54 PM, Steve Davis wrote: > :: Attempted to lock the working file > svn lock c:\dev\Testrepo\NewDoc.txt > > Response: > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL > svn: E200035: Additional errors: > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL What if anything is in the httpd error_log? Can you capture the network traffic between the server and the client and post it (removing Authentication headers) for the LOCK request? > I’ve first seen this in a Bitnami 2.3.2.1 install, and to try to make sure > it’s > not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: > Same result. I'm not familiar with Bitnami Redmine, can you tell us what version of httpd you have with it? > I have tried a totally standalone collabnet svn server install of 1.8.5 on a > separate machine, and the locks on that are working. I then put 1.8.5 onto the > server where we’re seeing the problem and once again the same problem > occurred. > So this seems to be an issue occurring as a result of the configuration setup > we have on that server. We do make use of an access file on that server, so my > next test was to disable the access file setup and retry. This worked exactly > as expected (by using a checkout using the local file system), responding that > the file had been locked > > So, it would seem that this issue is related to the use of the following > httpd.conf settings: > LoadModule dav_svn_module modules/mod_dav_svn.so > LoadModule authz_svn_module modules/mod_authz_svn.s > And/or > > serving the files over https Doubtful. > And the related settings pointing to the relevant access authority file. This is more likely. Can you post your configuration?
Re: expanding custom keywords in dump
This is why you don't use keywords if you can avoid it, especially for multi-environment projects. Frankly, you will often have diffs with keywords and "svn:eol-style": Don't evey try to pretend that anything with keywords is going to be byte for byte consistent between working environments. And this is *especially* why you don't use "custom keywords". They're not porable. On Fri, Jan 31, 2014 at 8:27 AM, Thorsten Schöning wrote: > Guten Tag Julian Elischer, > am Freitag, 31. Januar 2014 um 11:07 schrieben Sie: > >> [...]"$FreeBSD$" keyword is left unexpanded on export. > > This doesn't seem to be a keyword which svn clients expand by default, > therefore you would have two building lots. > > http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html > > 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...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow >
Re: expanding custom keywords in dump
On 1/31/14, 8:00 PM, Nico Kadel-Garcia wrote: > This is why you don't use keywords if you can avoid it, especially for > multi-environment projects. Frankly, you will often have diffs with > keywords and "svn:eol-style": Don't evey try to pretend that anything > with keywords is going to be byte for byte consistent between working > environments. > > And this is *especially* why you don't use "custom keywords". They're > not porable. > > On Fri, Jan 31, 2014 at 8:27 AM, Thorsten Schöning >> This doesn't seem to be a keyword which svn clients expand by default, >> therefore you would have two building lots. >> >> http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html Branko gave a perfectly reasonable answer. Beyond that I honestly don't get the point of these two emails. FreeBSD uses keywords because as an open source project they ship source. Even more importantly they have downstream projects (e.g. Apple uses their find command http://opensource.apple.com/source/shell_cmds/shell_cmds-175/find/main.c ). I can't think of a better way of tracking versioning for them once the source leaves their version control system and potentially goes into another. Yes there are all sorts of annoying bits about this. Custom properties don't really make anything more difficult. Since custom properties are repository dictated configuration. In fact the custom property feature was written by the FreeBSD guys and then passed along upstream to ease this burden. They're not expecting Perforce to ever expand these. They stay literal in the source to show the base from upstream. The fact that Perforce doesn't expand it can be considered a feature. So if you're going to critique their technique, how about making a suggestion of a better technique. It's like a couple guys snickering in their Ferrari as a lorry goes by because he could have gotten there much faster in a Ferrari, even though the driver of the lorry only has the goal to get 10 tons of freight there not go fast.
