Re: svn copy not updating Last Changed Rev
Jon DeVree wrote on Mon, 29 Mar 2010 at 18:47 -0400: > In fact, it occured to me that this should be visible on any public > subversion repository that used a server side svn copy operation. Even > the repository of svn itself: > > Here is the most recent log entry for the build subdirectory of > subversion in the 1.6.9 tag: > > svn log --stop-on-copy > http://svn.apache.org/repos/asf/subversion/tags/1.6.9/build > > r901401 | hwright | 2010-01-20 17:08:30 -0500 (Wed, 20 Jan 2010) | 1 > line > > Tag 1.6.9 release with svn_version.h matching tarball. Actually, that's a wc-to-repos copy, not a server-side copy operation. > > > But if you request svn info on the same URL it shows a different > revision as the most recent change: > > $ svn info http://svn.apache.org/repos/asf/subversion/tags/1.6.9/build | grep > ^Last > Last Changed Author: hwright > Last Changed Rev: 884204 > Last Changed Date: 2009-11-25 12:23:50 -0500 (Wed, 25 Nov 2009) > > > >
Re: svn copy not updating Last Changed Rev
Jon DeVree wrote on Mon, 29 Mar 2010 at 17:57 -0400: > On Mon, Mar 29, 2010 at 23:53:43 +0300, Daniel Shahaf wrote: > > % svn info iota2 iota3 | grep "Last Changed Rev" > > Last Changed Rev: 2 > > Last Changed Rev: 3 > > > > Try it with a directory that includes files and subdirectories and > you'll be able to reproduce it. The actual directory used as the root of > the copy operation has the correct Last Changed Rev, as I noted already: > Oh, sorry. Here's the output for a directory with children: [[[ % svn cp -q A A2 % svn ci -q -m "r2: add A2" % svn cp -q ^/trunk/A ^/trunk/A3 -m "r3: add A3" % svn up -q % svn info A2 A3 | grep "Last Changed Rev" Last Changed Rev: 2 Last Changed Rev: 3 ### why do the following two differ? % svn info A2/mu A3/mu | grep "Last Changed Rev" Last Changed Rev: 2 Last Changed Rev: 1 % svn --version -q 1.7.0-dev-r925148 % ]]] The second 'info' command treats A2/mu and A3/mu differently, and I don't see any reason for it do do so. (i.e., this seems to be a bug.) > > SVN info on the root of the copy shows the expected information: > > > > $ svn info file:///tmp/svn-repo/branches/mine > > Last Changed Author: jadevree > > Last Changed Rev: 5 > > Last Changed Date: 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) > *nod* > It is the files and subdirectories of this that are wrong: > > > But SVN info on the file that got copied with the branch is wrong: > > > > $ svn info file:///tmp/svn-repo/branches/mine/file > > Last Changed Author: jadevree > > Last Changed Rev: 2 > > Last Changed Date: 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) > > And this is inconsistent with what svn log reports as the last change: > > > $ svn log file:///tmp/svn-repo/branches/mine/file > > > > r5 | jadevree | 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) | 1 line > > > > test branch > > > > r2 | jadevree | 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) | 1 line > > > > foo > > > > So, 'log' does consider the copy-of-a-parent as a change to the child, while 'info' doesn't. I'm not sure whether or not this is intentional. >
Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
Hi! We recently upggraded our svn server to 1.6.5 to enable the usage of the svn merge tracking capabilities but failed to use it in more than one project due unwanted properties changes set on unchanged files. This makes it very hard to keep track of the real changes vs. svn internal changes. We always merge the root directories so I'd expect svn:mergeinfo properties to occur only on the root directory node. In fact we receive property changes on files I'd be totally unaware why that one should differ! Here is my problem in a simple use case: 1) I created a /branches/1.1.x from /trunk in svn rev #3101 2) We continued developing on /trunk 3) Just to tryout the merge tracking feature I merged /branches/1.1.x back to /trunk Actually the branch does contain NO COMMIT at all! Expected result: I'd expect, that I receive exactly one filechange: A svn:mergeinfo property update on /trunk which indicates my merge 3101-3110. Actual results: ~~~ Actually the svn:mergeinfo of many (random) file are updated and I have absolutley no clue why! Here is one example: gets to /branches/1.1.x/views-xlsexport/src/test/java/setup/export/ExportTest.java:310 2-3110 /branches/wss-850_devel/views-xlsexport/src/test/java/setup/export/ExportTest. java:2622-2680 WTF? That branch "wss-850_devel" even no longer exists! On the parent directories "setup" the situation is similar: /branches/1.1.x/views-xlsexport/src/main/java/setup:3101-3113* /branches/wss-850_devel/views-xlsexport/src/main/java/setup:2622-2680 /trunk/views-xlsexport/src/main/java/setup:2-2590* I checked out and ressureceted that expunged branch wss-850_devel to check if svn:mergeinfo properties have been defined there. Negative. Questions: ~~ So is anybody able to give us a hint or explain what happens and/or what we do wrong? Or event better: Can anybody gives hints on the technical backgrounds? - Why do unrelated branches appear in my mergeinfo - Do I have wrong expectations that only one file should change? - Are svn:merginfos repository global or locally to a revision? - What does the /trunk related entry mean? I merged the dir to myself? Huh! - What does the asterix mean (3101-3113*) I very appreciate any hint or link to more detailled background information Thanks a lot for your time, attention and support! - Ben
Re: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
On Tue, Mar 30, 2010 at 11:47 AM, Ben wrote: > Hi! We recently upggraded our svn server to 1.6.5 to enable the usage of the > svn merge tracking capabilities but failed to use it in more than one project > due unwanted properties changes set on unchanged files. > > This makes it very hard to keep track of the real changes vs. svn internal > changes. > > We always merge the root directories so I'd expect svn:mergeinfo properties to > occur only on the root directory node. In fact we receive property changes on > files I'd be totally unaware why that one should differ! > > Here is my problem in a simple use case: > > 1) I created a /branches/1.1.x from /trunk in svn rev #3101 > > 2) We continued developing on /trunk > > 3) Just to tryout the merge tracking feature I merged > /branches/1.1.x back to /trunk > > Actually the branch does contain NO COMMIT at all! > > > Expected result: > > I'd expect, that I receive exactly one filechange: A svn:mergeinfo > property update on /trunk which indicates my merge 3101-3110. > > > Actual results: > ~~~ > Actually the svn:mergeinfo of many (random) file are updated and > I have absolutley no clue why! > > Here is one example: > > > gets to > > /branches/1.1.x/views-xlsexport/src/test/java/setup/export/ExportTest.java:310 > 2-3110 > > /branches/wss-850_devel/views-xlsexport/src/test/java/setup/export/ExportTest. > java:2622-2680 > > > WTF? That branch "wss-850_devel" even no longer exists! > > > On the parent directories "setup" the situation is similar: > > /branches/1.1.x/views-xlsexport/src/main/java/setup:3101-3113* > /branches/wss-850_devel/views-xlsexport/src/main/java/setup:2622-2680 > /trunk/views-xlsexport/src/main/java/setup:2-2590* > > I checked out and ressureceted that expunged branch wss-850_devel > to check if svn:mergeinfo properties have been defined there. > Negative. > > Questions: > ~~ > So is anybody able to give us a hint or explain what happens and/or what we do > wrong? > Or event better: Can anybody gives hints on the technical backgrounds? > > - Why do unrelated branches appear in my mergeinfo > - Do I have wrong expectations that only one file should change? > - Are svn:merginfos repository global or locally to a revision? > - What does the /trunk related entry mean? > I merged the dir to myself? Huh! > - What does the asterix mean (3101-3113*) > > I very appreciate any hint or link to more detailled background information I don't have time right now to analyze and explain your particular situation, but as for a link to detailed background information, you might want to read this article: http://www.collab.net/community/subversion/articles/merge-info.html Also, if I understood correctly, improvements are being made in this area for svn 1.7 (for starters, in 1.7 only subtrees affected by the merge will have their mergeinfo updated). But it's too early to tell how that will work out. Svn 1.7 is still at least a couple of months away... -- Johan
Aleatory error MKCOL when I import a new project
Hi! Two different users have the next problem when they try to import a new project to a new repository. The strange is that when I do the same operations, all is fine The errors obtained are (In tortoise): Error: Commit failed (details follow): Error: MKCOL of Error: '/svn/project_name/!svn/wrk/571b9d23-702e-e043-be33-bc8c654b511c/search/sear ch-util/src/test': Error: could not connect to server (http://server_name) ** Error: PUT of Error: '/svn/project_name/!svn/wrk/35a3e3fe-2046-4741-8b55-39c9afbc6743/site/site-t ool/tool/src/bundle/admin_nl.properties': Error: could not connect to server (http://server_name) Finished!: ** Error: MKCOL of Error: '/svn/project_name/!svn/wrk/65ca69e6-41aa-1f45-843b-1fe1c375b426/search/sear ch-impl/impl/src/java/org/sakaiproject/search/component/dao/impl': Error: could not connect to server (http://server_name) Finished!: ** The subversion server is 1.4.2 version (x86_64) and Tortoise Version is 1.6.6 ** Thanks!!!
svnadmin create not honoring sticky bit
Hi, I encountered an unexpected behaviour during a svnadmin create as a normal user. We have a setup where a normal user can create repositories below an SvnParentPath structure. The directories are setgroupid www, with ACLs allowing the user write permissions. When I create these directories as root, the permissions are passed down properly, everything works, except for that misbehaviour with sqlite and rep-cache.db. When I create a repository as a normal user (with the proper permissions), the sticky bit doesn't get passed down to the db directory, so all files and directories in there end up owned by the user's primary group, with all traces of www removed, thus not readable. I created a test case: cd /tmp mkdir test chgrp www test chmod 2770 test setfacl -m u:username:rwx test setfacl -m d:u:username:rwx test cd test svnadmin create test1 su - username -c "cd /tmp/test; svnadmin create test2" Result: ls -l total 16 drwxrws---+ 6 root www 4096 2010-03-30 14:07 test1 drwxrws---+ 6 username www 4096 2010-03-30 14:07 test2 ls -ld test1/db test2/db drwxrws---+ 6 root www 4096 2010-03-30 14:07 test1/db drwxrwx---+ 6 username www 4096 2010-03-30 14:07 test2/db ls -l test1/db/rep-cache.db test2/db/rep-cache.db -rw-r-+ 1 root www 4096 2010-03-30 14:07 test1/db/rep-cache.db -rw-r-+ 1 username users 4096 2010-03-30 14:07 test2/db/rep-cache.db ls -ld test1/db/revs test2/db/revs drwxrws---+ 3 root www 4096 2010-03-30 14:07 test1/db/revs drwxrwx---+ 3 username users 4096 2010-03-30 14:07 test2/db/revs Am I doing something wrong or am I too stupid to see the obvious? Is this possibly a bug? Best regards Ullrich Jans -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Otto Fößel, Jarkko Sairanen Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: weird merge
On Fri, Mar 26, 2010 at 5:11 PM, Tyler Roscoe wrote: > On Fri, Mar 26, 2010 at 03:17:54PM +0100, Xavier Noria wrote: >> Even if I try to fix it by hand with >> >> svn merge -r2:2909 ^/trunk --record-only >> >> a subsequent merge still tries to get 2 through 2909. Moreover >> >> svn propget svn:mergeinfo . >> >> returns nothing. > > Are you using a merge-capable client and server (svn >= 1.5.0)? Yes, server is 1.5.1 (r32289) and client is 1.6.5 (r38866). > What does svn say after you perform the record-only merge? Nothing? Nothing, silent. >> Another fact is that svn log in the branch contains everything down to r1. > > What about svn log --stop-on-copy? > > When was your branch created (what revision)? I am doing ad-hoc tests with temporary branches I can throw. For example the last one was created from trunk r28935 and now trunk is r28939. Indeed if you want me to try something please just tell me, I can create whatever, test stuff and delete later. I don't know whether this is relevant, but we are not creating the branches exactly below the branches directory, but in a subdirectory of it.
Re: svnadmin create not honoring sticky bit
On Tue, Mar 30, 2010 at 02:16:50PM +0200, ullrich.j...@elektrobit.com wrote: > cd /tmp > mkdir test > chgrp www test > chmod 2770 test > setfacl -m u:username:rwx test > setfacl -m d:u:username:rwx test > cd test > svnadmin create test1 > su - username -c "cd /tmp/test; svnadmin create test2" > > Result: > > ls -l > total 16 > drwxrws---+ 6 root www 4096 2010-03-30 14:07 test1 > drwxrws---+ 6 username www 4096 2010-03-30 14:07 test2 > ls -ld test1/db test2/db > drwxrws---+ 6 root www 4096 2010-03-30 14:07 test1/db > drwxrwx---+ 6 username www 4096 2010-03-30 14:07 test2/db > ls -l test1/db/rep-cache.db test2/db/rep-cache.db > -rw-r-+ 1 root www 4096 2010-03-30 14:07 test1/db/rep-cache.db > -rw-r-+ 1 username users 4096 2010-03-30 14:07 test2/db/rep-cache.db See http://subversion.tigris.org/issues/show_bug.cgi?id=3437 Stefan
svn:eol-style does not work on update
Hello, i've enabled enable-auto-props=yes and *.php=svn:eol-style:native on linux... but when i "svn update" i still have msdos linefeeds in the php file... even when i delete the php file before updating.. i am using only the client... no idea where or what the server is... Dirk
svn:eol-style does not work on update
Hello, i've enabled enable-auto-props=yes and *.php=svn:eol-style:native on linux... but when i "svn update" i still have msdos linefeeds in the php file... even when i delete the php file before updating.. i am using only the client... no idea where or what the server is... Dirk
RE: svn:eol-style does not work on update
> Hello, > > i've enabled > > enable-auto-props=yes > > and > > *.php=svn:eol-style:native > > on linux... > > but when i "svn update" i still have msdos linefeeds in the > php file... even when i delete the php file before updating.. > > i am using only the client... no idea where or what the server is... The auto-prop feature works only on new files when you svn add them. So if these are files that were already in the repository they probably do not have the svn:eol-style property set, or have it set to CRLF. You will have to fix the EOL, with something like dos2unix probably, then manually change the property to native and finally commit so that next time they should have the correct EOL. Giulio Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851VAT Reg No 778499447
Re: svn:eol-style does not work on update
Hi Dirk, On Tue, Mar 30, 2010 at 04:05:12PM +0200, Dirk wrote: > i've enabled > > enable-auto-props=yes > > and > > *.php=svn:eol-style:native > > on linux... > > but when i "svn update" i still have msdos linefeeds in the php file... even > when i delete the php file before updating.. The auto-props only work for add and import. You need to set them manually for files which are already there. It should be possible to set them after checkout: svn propset svn:eol-sty.e native yourfile.php Then commit. Maybe you need to delete the file and "svn update" it again to make SVN check out a fresh copy - I'm not sure how it behaves. HTH, Tino. -- "What we nourish flourishes." - "Was wir nähren erblüht." www.lichtkreis-chemnitz.de www.tisc.de
RE: weird merge
> On Fri, Mar 26, 2010 at 5:11 PM, Tyler Roscoe wrote: > > > On Fri, Mar 26, 2010 at 03:17:54PM +0100, Xavier Noria wrote: > >> Even if I try to fix it by hand with > >> > >> svn merge -r2:2909 ^/trunk --record-only > >> > >> a subsequent merge still tries to get 2 through 2909. Moreover Did you do a commit after doing the --record-only merge? BOb > >> > >> svn propget svn:mergeinfo . > >> > >> returns nothing. > > > > Are you using a merge-capable client and server (svn >= 1.5.0)? > > Yes, server is 1.5.1 (r32289) and client is 1.6.5 (r38866). > > > What does svn say after you perform the record-only merge? Nothing? > > Nothing, silent. > > >> Another fact is that svn log in the branch contains everything down to > r1. > > > > What about svn log --stop-on-copy? > > > > When was your branch created (what revision)? > > I am doing ad-hoc tests with temporary branches I can throw. For > example the last one was created from trunk r28935 and now trunk is > r28939. > > Indeed if you want me to try something please just tell me, I can > create whatever, test stuff and delete later. > > I don't know whether this is relevant, but we are not creating the > branches exactly below the branches directory, but in a subdirectory > of it.
RE: svnadmin create not honoring sticky bit
Stefan Sperling wrote: > On Tue, Mar 30, 2010 at 02:16:50PM +0200, > ullrich.j...@elektrobit.com wrote: >> ls -l test1/db/rep-cache.db test2/db/rep-cache.db >> -rw-r-+ 1 root www 4096 2010-03-30 14:07 test1/db/rep-cache.db >> -rw-r-+ 1 username users 4096 2010-03-30 14:07 test2/db/rep-cache.db > > See http://subversion.tigris.org/issues/show_bug.cgi?id=3437 I know about that one. (That's why I mentioned it in my original mail) What's new (to me) is the permissions on *all* the files in db (just one example from db to keep the email short): drwxrws---+ 3 root www 4096 2010-03-30 14:07 test1/db/revs drwxrwx---+ 3 username users 4096 2010-03-30 14:07 test2/db/revs Looking at the main directory shows that the sticky bit on db got dropped: ls -l test2 total 48 drwxrws---+ 2 username www 4096 2010-03-30 14:07 conf drwxrwx---+ 6 username www 4096 2010-03-30 14:07 db ^here -r--r-+ 1 username www2 2010-03-30 14:07 format drwxrws---+ 2 username www 4096 2010-03-30 14:07 hooks drwxrws---+ 2 username www 4096 2010-03-30 14:07 locks -rw-rw+ 1 username www 229 2010-03-30 14:07 README.txt Occurred on svn 1.6.9 (package from the Suse Buildservice): subversion-1.6.9-4.3 subversion-perl-1.6.9-4.3 subversion-tools-1.6.9-4.3 subversion-server-1.6.9-4.3 Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Otto Fößel, Jarkko Sairanen Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: svn:eol-style does not work on update
Tino Schwarze wrote: > Hi Dirk, > > On Tue, Mar 30, 2010 at 04:05:12PM +0200, Dirk wrote: > >> i've enabled >> >> enable-auto-props=yes >> >> and >> >> *.php=svn:eol-style:native >> >> on linux... >> >> but when i "svn update" i still have msdos linefeeds in the php file... even >> when i delete the php file before updating.. > > The auto-props only work for add and import. You need to set them > manually for files which are already there. It should be possible to set > them after checkout: > svn propset svn:eol-sty.e native yourfile.php > > Then commit. Maybe you need to delete the file and "svn update" it again > to make SVN check out a fresh copy - I'm not sure how it behaves. > > HTH, > > Tino. > Thanks. :)
Re: weird merge
On Tue, Mar 30, 2010 at 4:25 PM, Bob Archer wrote: >> On Fri, Mar 26, 2010 at 5:11 PM, Tyler Roscoe wrote: >> >> > On Fri, Mar 26, 2010 at 03:17:54PM +0100, Xavier Noria wrote: >> >> Even if I try to fix it by hand with >> >> >> >> svn merge -r2:2909 ^/trunk --record-only >> >> >> >> a subsequent merge still tries to get 2 through 2909. Moreover > > > Did you do a commit after doing the --record-only merge? Nope, someone else in the project did. Right after I branched from trunk: cd into branches/someplace svn co branchURL cd branch name now to check the strange behavior: svn merge --dry-run ^/trunk confirm the mysterious r2 to r2909 appearing, with tree conflicts etc. (they are really old). svn log on the other side shows all the history down to r1. Then svn merge -r2:2909 ^/trunk --record-only Just returns a prompt, silently, and if we try again svn merge --dry-run ^/trunk that still tries to merge r2 to r2909.
Re: Can checkout and commit but NOT diff or display logs for files or dirs
Från: Johan Corveleyn [jcor...@gmail.com] Skickat: den 30 mars 2010 00:14 Till: Björn Blissing Kopia: users@subversion.apache.org Ämne: Re: Can checkout and commit but NOT diff or display logs for files or dirs 2010/3/29 Björn Blissing : > Hi, > > I set up a repo on my computer. I run the daemon with the following options: > >>svnserve.exe -d -r d:\svndata > > I can then check out and commit to the repo using "svn co > svn://localhost/project/trunk project" , BUT I can not do any diff or show > logs. > But if I instead checkout the repo using "svn co > file:///d:/svndata/project/trunk project" everything works perfectly. > > I have tried to run in listen-once mode with logging to a log file. And I get > this line when trying to diff the file readme.txt from the current > revision(10) to revision 8. > > 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata open 2 > cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) > /project/trunk/readme.txt SVN/1.6.6%20(r40053) - > 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata get-locations > /project/trunk/readme@10 (8) > > I am running Windows Vista 64 bit and Subversion 1.6.6. The svnserve.exe is > added to the firewall exceptions list. > > Anyone got any ideas of what is going wrong here? I have ran out of fresh > ideas... What's the exact command that you're running for diff or log? And what's the error message (if any) that you get from your svn client? -- Johan The error messages I get when trying to diff is: svn: Unreadable path encountered; access denied And when I try to show log is: svn: Item is not readable /Bjorn
Re: Can checkout and commit but NOT diff or display logs for files or dirs
Från: Johan Corveleyn [jcor...@gmail.com] Skickat: den 30 mars 2010 00:14 Till: Björn Blissing Kopia: users@subversion.apache.org Ämne: Re: Can checkout and commit but NOT diff or display logs for files or dirs 2010/3/29 Björn Blissing : > Hi, > > I set up a repo on my computer. I run the daemon with the following options: > >>svnserve.exe -d -r d:\svndata > > I can then check out and commit to the repo using "svn co > svn://localhost/project/trunk project" , BUT I can not do any diff or show > logs. > But if I instead checkout the repo using "svn co > file:///d:/svndata/project/trunk project" everything works perfectly. > > I have tried to run in listen-once mode with logging to a log file. And I get > this line when trying to diff the file readme.txt from the current > revision(10) to revision 8. > > 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata open 2 > cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) > /project/trunk/readme.txt SVN/1.6.6%20(r40053) - > 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata get-locations > /project/trunk/readme@10 (8) > > I am running Windows Vista 64 bit and Subversion 1.6.6. The svnserve.exe is > added to the firewall exceptions list. > > Anyone got any ideas of what is going wrong here? I have ran out of fresh > ideas... What's the exact command that you're running for diff or log? And what's the error message (if any) that you get from your svn client? -- Johan I run diff from the command prompt with: d:\project> svn diff readme.txt -r 8 The error messages I get when trying to diff is: svn: Unreadable path encountered; access denied For log I run: d:\project> svn log readme.txt And then I get the following error message: svn: Item is not readable /Bjorn
How to determine the source of a copy
Various client tools seem to know what path and revision a copy was created from (e.g., Tortoise's revision graph). Can the svn command line tool get me this information? Is there anyway I can get this from a hook script? Here's the context: I want to enforce that all code has gone through automated tested before being tagged. To do so, I planned to "pre-submit" tag requests to a gate-keeper, specifying the source path and revision. The gate-keeper then puts that revision through the tests, and if it passes, creates a signed authentication token specific to that path and revision. A pre-commit hook script will ensure that token is present and valid in the log message before allowing content to be tagged. For this to be effective, I need the token to be tied to the tested content. The most direct way I thought of was to create a string indicating the path and revision that was tested, and then digitally sign it. But to verify it, I then need my hook script to be able to identify what path and revision the commit is copied from, and to verify that there are no modifications included in the commit. Is this possible? My work around in the mean time is to use a combination of commands (ls, cat, proplist) to create a complete dump of the tested content, then hash and sign that dump. But it's pretty slow and pretty inelegant. (FYI, I'm not using svadmin dump because my gatekeeper doesn't necessarily have local access to the repository). Any suggestions would be great. Thanks, -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net
Re: Can checkout and commit but NOT diff or display logs for files or dirs
2010/3/30 Björn Blissing : > > > Från: Johan Corveleyn [jcor...@gmail.com] > Skickat: den 30 mars 2010 00:14 > Till: Björn Blissing > Kopia: users@subversion.apache.org > Ämne: Re: Can checkout and commit but NOT diff or display logs for files or > dirs > > 2010/3/29 Björn Blissing : >> Hi, >> >> I set up a repo on my computer. I run the daemon with the following options: >> >>>svnserve.exe -d -r d:\svndata >> >> I can then check out and commit to the repo using "svn co >> svn://localhost/project/trunk project" , BUT I can not do any diff or show >> logs. >> But if I instead checkout the repo using "svn co >> file:///d:/svndata/project/trunk project" everything works perfectly. >> >> I have tried to run in listen-once mode with logging to a log file. And I >> get this line when trying to diff the file readme.txt from the current >> revision(10) to revision 8. >> >> 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata open 2 >> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) >> /project/trunk/readme.txt SVN/1.6.6%20(r40053) - >> 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata get-locations >> /project/trunk/readme@10 (8) >> >> I am running Windows Vista 64 bit and Subversion 1.6.6. The svnserve.exe is >> added to the firewall exceptions list. >> >> Anyone got any ideas of what is going wrong here? I have ran out of fresh >> ideas... > > What's the exact command that you're running for diff or log? And > what's the error message (if any) that you get from your svn client? > > -- > Johan > > I run diff from the command prompt with: > d:\project> svn diff readme.txt -r 8 > > The error messages I get when trying to diff is: > svn: Unreadable path encountered; access denied > > For log I run: > d:\project> svn log readme.txt > > And then I get the following error message: > svn: Item is not readable Hm, that sounds like an authorization problem (access denied, ...). Are you using path-based authorization (an authz file referenced by your svnserve.conf)? I'm not sure (not much experience with path-based authz), but maybe you're being hit by issue #3242: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 If I understand correctly from that issue, checkouts work, but some operations (notably copying) fail, if you don't have read access to the root of the repository. It doesn't talk about diff and log though ... -- Johan
Re: Can checkout and commit but NOT diff or display logs for files or dirs [SOLVED]
Från: Johan Corveleyn [jcor...@gmail.com] Skickat: den 30 mars 2010 21:31 Till: Björn Blissing Kopia: users@subversion.apache.org Ämne: Re: Can checkout and commit but NOT diff or display logs for files or dirs 2010/3/30 Björn Blissing : > > > Från: Johan Corveleyn [jcor...@gmail.com] > Skickat: den 30 mars 2010 00:14 > Till: Björn Blissing > Kopia: users@subversion.apache.org > Ämne: Re: Can checkout and commit but NOT diff or display logs for files or > dirs > > 2010/3/29 Björn Blissing : >> Hi, >> >> I set up a repo on my computer. I run the daemon with the following options: >> >>>svnserve.exe -d -r d:\svndata >> >> I can then check out and commit to the repo using "svn co >> svn://localhost/project/trunk project" , BUT I can not do any diff or show >> logs. >> But if I instead checkout the repo using "svn co >> file:///d:/svndata/project/trunk project" everything works perfectly. >> >> I have tried to run in listen-once mode with logging to a log file. And I >> get this line when trying to diff the file readme.txt from the current >> revision(10) to revision 8. >> >> 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata open 2 >> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) >> /project/trunk/readme.txt SVN/1.6.6%20(r40053) - >> 1736 2010-03-29T17:41:31.690740Z 127.0.0.1 - svndata get-locations >> /project/trunk/readme@10 (8) >> >> I am running Windows Vista 64 bit and Subversion 1.6.6. The svnserve.exe is >> added to the firewall exceptions list. >> >> Anyone got any ideas of what is going wrong here? I have ran out of fresh >> ideas... > > What's the exact command that you're running for diff or log? And > what's the error message (if any) that you get from your svn client? > > -- > Johan > > I run diff from the command prompt with: > d:\project> svn diff readme.txt -r 8 > > The error messages I get when trying to diff is: > svn: Unreadable path encountered; access denied > > For log I run: > d:\project> svn log readme.txt > > And then I get the following error message: > svn: Item is not readable Hm, that sounds like an authorization problem (access denied, ...). Are you using path-based authorization (an authz file referenced by your svnserve.conf)? I'm not sure (not much experience with path-based authz), but maybe you're being hit by issue #3242: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 If I understand correctly from that issue, checkouts work, but some operations (notably copying) fail, if you don't have read access to the root of the repository. It doesn't talk about diff and log though ... -- Johan Yep, you are perfectly right. Just adding my user with read/write access wasn't enough. I had to give universal read access to the root folder of my repository. So now my authz file looks like this: [/] * = r bjornb = rw Thank you for clearing this mess for me. Best regards Björn
Re: svn:eol-style does not work on update
On Tue, 2010-03-30 at 16:05 +0200, Dirk wrote:
> Hello,
>
> i've enabled
>
> enable-auto-props=yes
>
> and
>
> *.php=svn:eol-style:native
>
> on linux...
>
> but when i "svn update" i still have msdos linefeeds in the php file... even
> when i delete the php file before updating..
>
> i am using only the client... no idea where or what the server is...
>
>
>
> Dirk
There is a svn_apply_autoprops as part of the subversion distribution
(in contrib, I think), which will apply your current auto props to a
working copy.
My current copy of that script is attached - needs python.
I use it a lot, and it works well for me.
Tony Butt
CEA Technologies
--
Tony Butt
#!/usr/bin/python
# This script reads the auto-properties defined in the
# $HOME/.subversion/config file and applies them recursively to all
# the files and directories in the current working copy. It may
# behave differently than the Subversion command line; where the
# subversion command line may only apply a single matching
# auto-property to a single pathname, this script will apply all
# matching lines to a single pathname.
#
# To do:
# 1) Switch to using the Subversion Python bindings.
# 2) Allow a command line option to specify the configuration file to
#load the auto-properties from.
#
# $HeadURL: http://svn.collab.net/repos/svn/branches/1.6.x/contrib/client-side/svn_apply_autoprops.py $
# $LastChangedRevision: 20787 $
# $LastChangedDate: 2006-07-20 03:41:28 + (Thu, 20 Jul 2006) $
# $LastChangedBy: blair $
#
# Copyright (C) 2005,2006 Blair Zajac
#
# This script is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This script is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# A copy of the GNU General Public License can be obtained by writing
# to the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
# Boston, MA 02111-1307 USA.
import fnmatch
import os
import re
import sys
# The path to the Subversion configuration file.
SVN_CONFIG_FILENAME = '$HOME/.subversion/config'
# The name of Subversion's private directory in working copies.
SVN_WC_ADM_DIR_NAME = '.svn'
def get_autoprop_lines(fd):
lines = []
reading_autoprops = 0
re_start_autoprops = re.compile('^\s*\[auto-props\]\s*')
re_end_autoprops = re.compile('^\s*\[\w+\]\s*')
for line in fd.xreadlines():
if reading_autoprops:
if re_end_autoprops.match(line):
reading_autoprops = 0
continue
else:
if re_start_autoprops.match(line):
reading_autoprops = 1
continue
if reading_autoprops:
lines += [line]
return lines
def process_autoprop_lines(lines):
result = []
for line in lines:
# Split the line on the = separating the fnmatch string from the
# properties.
try:
(fnmatch, props) = line.split('=', 1)
except ValueError:
continue
# Remove leading and trailing whitespace from the fnmatch and
# properties.
fnmatch = fnmatch.strip()
props = props.strip()
# Create a list of property name and property values. Remove all
# leading and trailing whitespce from the propery names and
# values.
props_list = []
for prop in props.split(';'):
prop = prop.strip()
if not len(prop):
continue
try:
(prop_name, prop_value) = prop.split('=', 1)
prop_name = prop_name.strip()
prop_value = prop_value.strip()
except ValueError:
prop_name = prop
prop_value = '*'
if len(prop_name):
props_list += [(prop_name, prop_value)]
result += [(fnmatch, props_list)]
return result
def filter_walk(autoprop_lines, dirname, filenames):
# Do no descend into directories that do not have a .svn directory.
try:
filenames.remove(SVN_WC_ADM_DIR_NAME)
except ValueError:
filenames = []
print "Will not process files in '%s' because it does not have a '%s' " \
"directory." \
% (dirname, SVN_WC_ADM_DIR_NAME)
return
filenames.sort()
# Find those filenames that match each fnmatch.
for autoprops_line in autoprop_lines:
fnmatch_str = autoprops_line[0]
prop_list = autoprops_line[1]
matching_filenames = fnmatch.filter(filenames, fnmatch_str)
if not matching_filenames:
continue
for prop in prop_list:
command = ['svn', 'propset', prop[0], prop[1]]
for f in matching_filenames:
command += ["%s/%s" % (dirname, f)]
status = os.spawnvp(os.P_WAIT, 'svn', command)
if status:
print 'Command "%s" failed with exit status %s' \
% (command, status)
sys.exit(1)
def main():
config_filename = os.path.expand
Re: weird merge
Can I tell to svn that it totally forget revisions < 3000 ? Those are very old and we could just get rid of them it there was a chance that it solved the issue, it is a pity we need to deal with explicit revisions all the time, reflective merges... I don't know, perhaps around r2909 people did something with the repo, upgrading, ... no idea.
Re: svn:eol-style does not work on update
> There is a svn_apply_autoprops as part of the subversion distribution > (in contrib, I think), which will apply your current auto props to a > working copy. > > My current copy of that script is attached - needs python. > > I use it a lot, and it works well for me. > Tony Butt > CEA Technologies Thanks. I already tried Tino's tip and it worked. The msdos linefeeds are gone permanently.
Re: weird merge
On Mar 30, 2010, at 18:55, Xavier Noria wrote: > Can I tell to svn that it totally forget revisions < 3000 ? Doing so is a very invasive procedure. I don't recommend it. It's likely to cause more problems than it solves. > Those are > very old and we could just get rid of them it there was a chance that > it solved the issue, it is a pity we need to deal with explicit > revisions all the time, reflective merges... > > I don't know, perhaps around r2909 people did something with the repo, > upgrading, ... no idea.
Re: Problem creating new repo
On Monday 29 Mar 2010, Campbell Allan wrote: > On Monday 29 Mar 2010, Randi Hillerøe wrote: > > For 4 hours I have tried to solve this problem but seems like very few > > had it before. > > > > I just installed subversion on a QNAP T410, NAS, which completed all fine > > however it went wrong when I tried to create the first repository. > > > > I use the command: svnadmin create repo_path > > But in a few moments it just says "Illegal instruction" - which I really > > can't figure out what means... > > > > I tried to delete the directory, make it again and create again, but > > every time the samme... About half the files are missing and I really > > can't figure out why... > > > > Is there any way to get som more debugging information than just "Illegal > > instruction"? > > > > Anyone knowing how to solve this problem? > > > > If you need any more information please ask. > > > > -Silwing > > The illegal instruction error sounds like the binary isn't quite compatible > with the processor in the nas. I'd suggest trying a different source for > the binaries or compiling them yourself. The latter would be better as you > can tweak the compiler flags to deal with the illegal op but getting the > compiler in the first place might be tricky. I don't recall seeing it the > last time I looked at the packages available on ipkg nor could I find a > compatible cross compiler environment. Sorry :/ > > I've got a T109-II, I'll give it a shot tonight myself and see if I also > have the problem but without a compiler environment I don't see how it > might be fixed. > > Campbell Hi, as I promised I tried this out on my TS109-II. It should be a reasonable comparison as both devices use a Marvel based arm compatible CPU. I didn't get an illegal instruction error when creating the repository but did have trouble importing. I've not dug into that problem much yet but can if you wish. Can you check your package sources against the list below? After running an ipkg update, ipkg install svn read the following packages in from: http://ipkg.nslu2-linux.org/feeds/optware/cs05q1armel/cross/unstable/ svn_1.6.9-1_arm.ipk neon_0.29.3-1_arm.ipk libxml2_2.7.7-1_arm.ipk apr_1.3.12-1_arm.ipk apr-util_1.3.9-1_arm.ipk e2fslibs_1.40.3-1_arm.ipk expat_2.0.1-1_arm.ipk cyrus-sasl-libs_2.1.23-1_arm.ipk openldap-libs_2.3.43-1_arm.ipk if they differ, especially the URL can you try an update or explicitly downloading the ipk files and installing them directly? Cheers, Campbell -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Usage of Subversion in Intersystem's Cache
Dear Madam/Sir, We are doing Projects using Intersystem's Cache. We have downloaded the 'Subversion for Win32, version 1.4.6.' for Source Control issues in our project. We installed the tool and read the documentation (svn-book), but there is no topic related to working with Intersystem's Cache. You provided the tool only for DOS mode. May I know the steps to use this Subversion in Cache studio else if you have any other tools that support the Source control issues in Intersystem's Cache? Regards Shajahan A Software Engineer.
Re: Usage of Subversion in Intersystem's Cache
On Wed, Mar 31, 2010 at 00:24, Shajahan Mohammed wrote: > Dear Madam/Sir, > > > > We are doing Projects using Intersystem's Cache. We have > downloaded the 'Subversion for Win32, version 1.4.6.' for Source Control > issues in our project. We installed the tool and read the documentation > (svn-book), but there is no topic related to working with Intersystem's > Cache. You provided the tool only for DOS mode. May I know the steps to use > this Subversion in Cache studio else if you have any other tools that > support the Source control issues in Intersystem's Cache? > You have downloaded a very old release of Subversion which is no longer supported beyond critical security fixes. This is not an Intersystem Cache support mailing list. I'd wager that 90% of the participants here have never even heard of it. I suggest you ask in a support venue for that product. This was the best I could find with a quick Google search. http://groups.google.com/group/intersystems-public-cache/browse_thread/thread/c54f8814a1cd1922/19e81d720add9e49?lnk=raot&pli=1
