RE: Repository Directory Tree
Please don't top post. On this ML the net-etiquette requires you to post your reply at the bottom > Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Aladdin [mailto:alad...@csunv.com] > Sent: 12 September 2010 19:56 > To: users@subversion.apache.org > Subject: RE: Repository Directory Tree > > Oops! Sorry- should ALWAYS RTFM!! I used " svn up > NetDataSvc --force", and it *seemed* to work! > > Is this what I should have done, and now will need to do for > each project I check out for the first time after doing this? > > Regards, > Allen > > > -Original Message- > > From: Aladdin [mailto:alad...@csunv.com] > > Sent: Sunday, September 12, 2010 2:48 PM > > To: 'Giulio Troccoli'; users@subversion.apache.org > > Subject: RE: Repository Directory Tree > > > > Giulio, > > > > That seemed to work well, except now when I try to checkout > one of my > > projects, I get this: > > > > anw-dev:/home/anw/TechProjects# svn co file:///var/svn/NetDataSvc . > > svn: Failed to add directory 'NotUsed': an unversioned directory of > > the same name already exists > > > > "NotUsed" contains, as the name implies, a couple of C++ > and .h source > > files that I'm not currently using but wanted to hang on > to. It is a > > subdirectory under NetDataSvc. >From the error message I guess /home/anw/TechProjects was not empty when you >tried the checkout. Using the --force option you have overwritten the content >of /home/anw/TechProjects/NotUsed with whatever it was in the repository (it >should have left untouched all those files that are not in the repository). I don't know whether that was what you should have done. Maybe, or maybe not. Only you can be the judge of that, because you know what was in that directory before you check your working copy out. As per having to do use --force every time, I wouldn't think so. I mean, you would need to make a judgement call if you already have a NotUsed directory, but if you do everytime, I would question why you do. I personally would check out a fresh new working copy in a non, yet, existing directory. G
RE: Repository Directory Tree
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > Sent: 10 September 2010 23:01 > To: Lorenz > Cc: users@subversion.apache.org > Subject: Re: Repository Directory Tree > > On Fri, Sep 10, 2010 at 5:57 PM, Nico Kadel-Garcia > wrote: > > On Fri, Sep 10, 2010 at 1:42 AM, Lorenz wrote: > >> Giulio Troccoli wrote: > >>>[...] > >>>- check out the whole thing (it might be too big but maybe not) > >>> svn checkout file:///var/svn ~/tmp This will create a new > >>>directory called tmp in your home directory whit the whole > of your repository. > >>>Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 > and var/svn/proj3. > >>> > >>>- move the projects to the root of your repository > >>> cd ~/tmp > >>> svn move var/svn/proj1 proj1 > >>> svn move var/svn/proj2 proj2 > >>> svn move var/svn/proj3 proj3 > >>>Since you have used svn command the history will be preserved. > >>> > >>>- commit > >>> svn commit -m"Reorganising the projects" > >> > >> if you don't want to check-out the whole repository, and > are working > >> from the command line anyway, you can use svnmucc to do the > >> restructuring in one commit without a working copy. > >> > >>svnmucc mv url1 url2 mv url3 url4 ... > >> -- > > > > What, exactly, is wrong with: > > > > Gahh, web interface messed with my use of tabs in typing: > > What's wrong with this syntax to do the move without a checkout? > > svn move [URLOFREPO]/var/svn/proj1 [URLOFREPO/proj1 Nothing at all. I personally prefer to do all my restructuring in a working copy and commit once I'm happy, that's why I suggested that way. G
Re: Does svn merge --reintegrate ^URL syntax really work ?
Thank you Daniel! I've reported it to svnbook list here: http://code.google.com/p/svnbook/issues/detail?id=97 Daniel Shahaf-2 wrote: > > LiuYan 刘研 wrote on Fri, Sep 10, 2010 at 00:19:54 -0700: >> >> Thank you Erik, >> >> 1. I think I got the cause: >> I use Subversion in windows system, it's a little different to linux/unix >> system: >> The ^ character is a special character in command prompt window or batch >> file. the ^ character and it's following characters MUST be quoted: > > Or doubled: ^^/trunk . And this is documented. > >> E:\Incoming\svntest\calc\branches\new-branch>svn list ^/ >> svn: '\' is not a working copy >> E:\Incoming\svntest\calc\branches\new-branch>svn list "^/" >> calc/ >> paint/ >> tools/ >> >> >> 2. But, >> beause ^ means "the URL of the repository's root directory”, why svn-book >> use ^/trunk instead of ^/calc/trunk ? >> > > It seems the book is inconsistent on whether 'calc' is a repository or > a directory inside a repository. Could you report this to the svnbook > list please? > > -- View this message in context: http://old.nabble.com/Does-svn-merge---reintegrate-%5EURL-syntax-really-work---tp29673121p29695674.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Repository Directory Tree
Nico Kadel-Garcia wrote: >On Fri, Sep 10, 2010 at 5:57 PM, Nico Kadel-Garcia wrote: >> On Fri, Sep 10, 2010 at 1:42 AM, Lorenz wrote: >>[...] >>> if you don't want to check-out the whole repository, and are working >>> from the command line anyway, you can use svnmucc to do the >>> restructuring in one commit without a working copy. >>> >>> svnmucc mv url1 url2 mv url3 url4 ... >>> -- >> >What's wrong with this syntax to do the move without a checkout? > > svn move [URLOFREPO]/var/svn/proj1 [URLOFREPO/proj1 nothing, just pointing out that it possible do to the rearrangement without a WC directly in the repo in one revision. For complicated rearrangements I would prefere the WC method myself, because I can revert/redo as long as I want until I'm satisfied - before commiting. -- Lorenz
SVN: password updating problem
Hi. Problem: 1. We're using large components, each built of dozens of SVN repositories. 2. Checking out such a component can take 6 hours (we call this operation 'populate'). 3. I.e., we want the populate to be as much automatic as possible. 4. Our IT department requires us to change password every few months. 5. Every time the password is changed, the populate procedure stops for several times, requesting for the new password. 6. Of course, there is local caching for 'known password's. However, updating password is a nightmare. Possible solution: * The password can be saved to a special environment setting (e.g. SVN_PASSWORD) * The password can be stored in the ~/.subversiom/.auto directory - Not caching after user has written the password; but storing the password beforehand. Thanks, Zvika
Re: SVN: password updating problem
On Sep 13, 2010, at 06:05, Zvika Haramaty wrote: > Problem: > • We’re using large components, each built of dozens of SVN > repositories. > • Checking out such a component can take 6 hours (we call this > operation ‘populate’). > • I.e., we want the populate to be as much automatic as possible. > • Our IT department requires us to change password every few months. > • Every time the password is changed, the populate procedure stops for > several times, requesting for the new password. > • Of course, there is local caching for ‘known password’s. However, > updating password is a nightmare. > > Possible solution: > • The password can be saved to a special environment setting (e.g. > SVN_PASSWORD) > • The password can be stored in the ~/.subversiom/.auto directory - > Not caching after user has written the password; but storing the password > beforehand. Have you considered using Subversion's existing --username, --password and --no-auth-cache arguments?
RE: Merge problem with different users
No, we don't use path-based authorization. All developers (accounts) have the same permissions (even the merge user account). Regarding the mergeinfo questions: the branch entry is "/9746-10001,10003-10205. The missing Rev 10002 was exactly the one that couldn't be merged due to the errors reported earlier. We merged the changes according to the description given here: http://blog.red-bean.com/sussman/?p=92 Michael -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Montag, 6. September 2010 14:27 To: Ungruhe, Michael Cc: users@subversion.apache.org; Strucken, Andreas Subject: Re: Merge problem with different users On Mon, Sep 06, 2010 at 02:44:30AM -0700, Ungruhe, Michael wrote: > The "merge user" is just a user account. Since we noticed that the > problem described earlier only occurs when the merging is made by > different users (on different user accounts), we created a new user > account (called mergeuser) that all developers use for merging (and > reintegration). So the users itself are still different, but they use > the same account. Ok, but do you have answers to my questions regarding mergeinfo? I'm trying to figure out where your problem is coming from, and so far, it sounds like one or more of your developers are doing merges in a way that prevents mergeinfo from being recorded correctly, for whatever reason. Another question: Do you use path-based authorisation? Do the accounts involved in the merges all have the same set of permissions, or are there differences that might explain your problems? Stefan
Re: how to browse older revisions?
> The easy approach is to install viewvc for browser viewing and > navigation.http://viewvc.org/ Yes, it is included in Subversion Edge of Collabnet. Ivan
Re: how to browse older revisions?
> > https://server/svn/project/trunk/?p= Thanks, this synatx works. Ivan
Re: SVN: password updating problem
On Mon, Sep 13, 2010 at 7:19 AM, Ryan Schmidt wrote: > > On Sep 13, 2010, at 06:05, Zvika Haramaty wrote: > >> Problem: >> • We’re using large components, each built of dozens of SVN >> repositories. >> • Checking out such a component can take 6 hours (we call this >> operation ‘populate’). >> • I.e., we want the populate to be as much automatic as possible. >> • Our IT department requires us to change password every few months. >> • Every time the password is changed, the populate procedure stops for >> several times, requesting for the new password. >> • Of course, there is local caching for ‘known password’s. However, >> updating password is a nightmare. >> >> Possible solution: >> • The password can be saved to a special environment setting (e.g. >> SVN_PASSWORD) >> • The password can be stored in the ~/.subversiom/.auto directory - >> Not caching after user has written the password; but storing the password >> beforehand. > > Have you considered using Subversion's existing --username, --password and > --no-auth-cache arguments? Storing the clear-text user passwords in ~/.subversion/.auto is *BAD, BAD, BAD, BAD* practice. Storing cleartext passwords would get people fired in every company I've set up subversion for, as a major security violation. And in fact, this does nothing to help that when the password changes. Have you considered switching to a dedicated Subversion user to manage the repository and using ssh+svn with SSH public keys, to avoid these password management issues? It requires some infrastructure to manage the keys, and there is still no well-publicized tool to do this, but it's workable. Or depending on your repository security requirements, what about non-secured read-only access to a central mirrored working copy to first duplicate the working copy, then doing "svn update" on it to bring it up to date? This is especially useful for CIFS users, since checking out a 1 Gig working copy to CIFS shares takes roughly 30 minutes in my experience, while simply duplicating the working copy takes about 3 minutes. This might save you a *lot* of time if that 6 hours is a checkout to a CIFS share.
SVN performance issue
Hi, Greetings of the day! I have a repository of 20gb on SVN hosted on LINUX operating system but its taking unusually long time to access it over rep browser. While the other repositories hosted on same box and with the same data size are working fine. I tried a lot but could not zero down to this performance issue. It would be really helpful if someone helps me on this. Thanks, Sakshi
svn doesnt work on one of my 3g connections
Hi, I have a rather odd problem where I cant use svn with one of my 3g connections. My main connection is a generic 3g usb modem which everything else works fine over (although slowly). I can ping the remote server fine (~430ms) and tracepath seems to be sane. If I try svn up it will just do nothing (I cant even ^C it). If I connect with my phone it all works fine. (Both connections are the same cell towers but apparently different routes out of the country) Attached is ping and tracepath for both connections (different local computers though it doesnt make any difference). Any ideas what could be the issue? Cheers Jonathan P.S $ svn --version svn, version 1.6.6 (r40053) compiled Dec 12 2009, 05:06:12 $ uname -a Linux thor 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux 3g connection that doesnt work $ ping svn.rockbox.org PING svn.rockbox.org (80.67.6.50) 56(84) bytes of data. 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=1 ttl=45 time=442 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=2 ttl=45 time=449 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=3 ttl=45 time=418 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=4 ttl=45 time=420 ms ^C64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=5 ttl=45 time=428 ms --- svn.rockbox.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4194ms rtt min/avg/max/mdev = 418.702/432.040/449.897/12.362 ms jo...@thor: ~ $ tracepath svn.rockbox.org 1: 111-220-222-221.wholesaledsl.com.au (111.220.222.221) 0.122ms pmtu 1500 1: flexilns02.wcg.net.au (125.168.67.2) 1459.926ms 1: flexilns02.wcg.net.au (125.168.67.2) 578.803ms 2: 125.168.67.46 (125.168.67.46) 200.410ms 3: 125.168.255.105 (125.168.255.105) 203.601ms 4: 125.168.255.106 (125.168.255.106) 224.122ms 5: 202.128.112.1 (202.128.112.1) 208.457ms 6: 119.225.2.181 (119.225.2.181) 270.463ms asymm 7 7: 10.250.21.3 (10.250.21.3) 220.721ms asymm 8 8: 61.88.241.111 (61.88.241.111) 223.343ms 9: 203.208.192.201 (203.208.192.201) 395.629ms asymm 10 10: no reply 11: te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69) 381.446ms 12: te0-0-0-5.mpd21.iah01.atlas.cogentco.com (154.54.2.197) 419.943ms 13: no reply 14: te0-2-0-3.ccr21.dca01.atlas.cogentco.com (154.54.24.9) 443.913ms 15: te0-4-0-1.mpd21.jfk02.atlas.cogentco.com (154.54.40.46) 469.961ms 16: te0-1-0-0.mpd21.jfk02.atlas.cogentco.com (154.54.25.141) 520.028ms asymm 20 17: te0-3-0-6.mpd22.ams03.atlas.cogentco.com (154.54.6.142) 581.240ms asymm 20 18: te0-2-0-0.ccr21.ham01.atlas.cogentco.com (130.117.50.46) 551.212ms asymm 16 19: te1-1.ccr02.sto01.atlas.cogentco.com (130.117.3.206) 548.641ms 20: te0-0-0-0.ccr21.ham01.atlas.cogentco.com (130.117.50.42) 529.978ms asymm 16 21: cgnt-126.kn1.sth.portlane.net (149.6.168.126) 522.645ms asymm 19 22: cgnt-122.kn1.sth.portlane.net (149.6.168.122) 550.439ms asymm 19 23: giant.haxx.se (80.67.6.50) 568.631ms reached Resume: pmtu 1500 hops 23 back 45 connection that does work $ ping svn.rockbox.org PING svn.rockbox.org (80.67.6.50) 56(84) bytes of data. 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=1 ttl=46 time=5130 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=2 ttl=46 time=4123 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=3 ttl=46 time=3115 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=4 ttl=46 time=2108 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=5 ttl=46 time=1106 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=6 ttl=46 time=603 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=7 ttl=46 time=523 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=8 ttl=46 time=431 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=9 ttl=46 time=439 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=10 ttl=46 time=438 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=11 ttl=46 time=518 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=12 ttl=46 time=486 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=13 ttl=46 time=589 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=14 ttl=46 time=585 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=15 ttl=46 time=435 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=16 ttl=46 time=433 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=17 ttl=46 time=659 ms 64 bytes from giant.haxx.se (80.67.6.50): icmp_seq=18 ttl=46 time=578 ms ^C --- svn.rockbox.org ping statistics --- 19 packets transmitted, 18 received, 5% packet loss, time 18038ms rtt min/avg/max/mdev = 431.173/1239.352/5130.797/1386.696 ms, pipe 6 jo...@netbook:~/rockbox$ tracepath svn.rockbox.org 1: netbook (192.168.43.146) 0.375ms pmtu 1500 1: 192.168.43.1 (192.168.43.1) 2.232ms 1: 192.168.43.1 (192.168.43.1) 2.095ms 2: 172.22.68.130 (172.22.68.130) 302.444ms asymm 3 3: 172.22.68.2 (172.22.68.2) 380.892ms 4: 58.145.152.57 (58.145.152.57) 1436.485ms asymm 3 4: 58.145.152.57 (58.145.152.57) 6052.166ms asymm 3 5: mas1-ge4-0.gw.optusnet.com.au (58.145.15
Re: Hook Script Examples
- Original Message > From: Ryan Schmidt > On Sep 10, 2010, at 10:50, BRM wrote: > > My old subversion server had a hookscript to deny commits unless there was > > a > >log > > > message. I'd like to setup the same functionality on the new subversion >server > > > too. > > I already got my hook-scripts in place, but... > Note the hook script to deny commits that have no log message is what you > get >in the default pre-commit.tmpl file that Subversion creates in every new >repository. Yes, that is very nice. I did have to add a message though - so that users would get some kind of feed back as to why it was denied. Where as the pre-revprop-change.templ provides some default log message info. > > > > In the process, I came across the following README files: > > > > http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/README > > http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/README > > ; > > both of which references the old tigris.org site: > > > > http://subversion.tigris.org/tools_contrib.htmlHoweve, the page is no > > longer > > > > available, and I can't find it on the new apache.org site either. > > Is this page just simply no longer going to be available? Or is there >somewhere > > > else for this stuff now? > > The files are here: > > http://svn.apache.org/repos/asf/subversion/trunk/contrib/ > > The tools_contrib.html page was removed earlier this year: > > http://svn.apache.org/viewvc?view=revision&revision=900549 That's fine; however, my point for bringing this up is that there is stuff still referencing that page. Those references should get updated. That's all. Ben
Re-integration Q...
I am running into the error: svn: Cannot reintegrate from 'url://feature-branch' yet: Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry. I came across a collab.net blog site[1] that referenced this issue. So I tried it in 1.6.6 too, which gave me a little more information - namely, one path in my branch seems to be missing a revision from trunk. In examining the svn:mergeinfo, it seems to be an 'off-by-one' - the svn:merge info records 5627:6031 as being merged but not 5626. I synced the branch using a 1.5.1 client; and running svn diff url-trunk url-branch produces only a delta in the svn:mergeinfo; so I am assuming the files are identical. The merge revision in question adds a folder and file. Reading more of the blog points to a forum[2], and following that I found a post[3] that references doing a record only merge, which I tried (using a 1.6.6 client), but it didn't seem to resolve the 'off-by-one' issue. So, is it: i) safe to just delete the svn:mergeinfo in this case? ii) is is safer/better to just 'svn pedit svn:mergeinfo' to include the extra revision? (e.g. edit 5627:6031 -> 5626:6013) Would 'ii' even work? If so, which is (a) better, (b) safer? I kind of lean towards 'i' since (1) it seems to be documented, and (2) the files do seem to be the same. But I'd like to understand this a little more before I do something. TIA, Ben [1]http://blogs.open.collab.net/svn/2008/07/subversion-merg.html [3]http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=99955
RE: Repository Directory Tree
> -Original Message- > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > Sent: Monday, September 13, 2010 3:52 AM > To: anw-d...@infoisland.net; users@subversion.apache.org > Subject: RE: Repository Directory Tree > > Please don't top post. On this ML the net-etiquette requires you to > post your reply at the bottom > > > > > Linedata Limited > Registered Office: 85 Gracechurch St., London, EC3V 0AA > Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 > > -Original Message- > > > > From: Aladdin [mailto:alad...@csunv.com] > > Sent: 12 September 2010 19:56 > > To: users@subversion.apache.org > > Subject: RE: Repository Directory Tree > > > > Oops! Sorry- should ALWAYS RTFM!! I used " svn up > > NetDataSvc --force", and it *seemed* to work! > > > > Is this what I should have done, and now will need to do for > > each project I check out for the first time after doing this? > > > > Regards, > > Allen > > > > > -Original Message- > > > From: Aladdin [mailto:alad...@csunv.com] > > > Sent: Sunday, September 12, 2010 2:48 PM > > > To: 'Giulio Troccoli'; users@subversion.apache.org > > > Subject: RE: Repository Directory Tree > > > > > > Giulio, > > > > > > That seemed to work well, except now when I try to checkout > > one of my > > > projects, I get this: > > > > > > anw-dev:/home/anw/TechProjects# svn co file:///var/svn/NetDataSvc . > > > svn: Failed to add directory 'NotUsed': an unversioned directory of > > > the same name already exists > > > > > > "NotUsed" contains, as the name implies, a couple of C++ > > and .h source > > > files that I'm not currently using but wanted to hang on > > to. It is a > > > subdirectory under NetDataSvc. > > From the error message I guess /home/anw/TechProjects was not empty > when you tried the checkout. Using the --force option you have > overwritten the content of /home/anw/TechProjects/NotUsed with whatever > it was in the repository (it should have left untouched all those files > that are not in the repository). > > I don't know whether that was what you should have done. Maybe, or > maybe not. Only you can be the judge of that, because you know what was > in that directory before you check your working copy out. As per having > to do use --force every time, I wouldn't think so. I mean, you would > need to make a judgement call if you already have a NotUsed directory, > but if you do everytime, I would question why you do. I personally > would check out a fresh new working copy in a non, yet, existing > directory. > > G Sorry about the top post. I'm also active on another mailing list regarding dovecot where you are *supposed* to top post. Again maybe I should have RTFM'd! OK- I think I understand. What the directory had in it was a copy of what I put into the repository; I hadn't made any changes since it went it went in, so it should be fine. All other directories similarly; so, if I understand correctly, if I delete them all first or just use --force to check them out, it should be the same. Thanks a bunch- Allen
RE: Repository Directory Tree
> > Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > > Sent: Monday, September 13, 2010 3:52 AM > > To: anw-d...@infoisland.net; users@subversion.apache.org > > Subject: RE: Repository Directory Tree > > > > Please don't top post. On this ML the net-etiquette requires you to > > post your reply at the bottom > > > > > > > > > Linedata Limited > > Registered Office: 85 Gracechurch St., London, EC3V 0AA > Registered in > > England and Wales No 3475006 VAT Reg No 710 3140 03 > > > > -Original Message- > > > > > > > From: Aladdin [mailto:alad...@csunv.com] > > > Sent: 12 September 2010 19:56 > > > To: users@subversion.apache.org > > > Subject: RE: Repository Directory Tree > > > > > > Oops! Sorry- should ALWAYS RTFM!! I used " svn up NetDataSvc > > > --force", and it *seemed* to work! > > > > > > Is this what I should have done, and now will need to do for each > > > project I check out for the first time after doing this? > > > > > > Regards, > > > Allen > > > > > > > -Original Message- > > > > From: Aladdin [mailto:alad...@csunv.com] > > > > Sent: Sunday, September 12, 2010 2:48 PM > > > > To: 'Giulio Troccoli'; users@subversion.apache.org > > > > Subject: RE: Repository Directory Tree > > > > > > > > Giulio, > > > > > > > > That seemed to work well, except now when I try to checkout > > > one of my > > > > projects, I get this: > > > > > > > > anw-dev:/home/anw/TechProjects# svn co > file:///var/svn/NetDataSvc . > > > > svn: Failed to add directory 'NotUsed': an unversioned > directory > > > > of the same name already exists > > > > > > > > "NotUsed" contains, as the name implies, a couple of C++ > > > and .h source > > > > files that I'm not currently using but wanted to hang on > > > to. It is a > > > > subdirectory under NetDataSvc. > > > > From the error message I guess /home/anw/TechProjects was not empty > > when you tried the checkout. Using the --force option you have > > overwritten the content of /home/anw/TechProjects/NotUsed with > > whatever it was in the repository (it should have left > untouched all > > those files that are not in the repository). > > > > I don't know whether that was what you should have done. Maybe, or > > maybe not. Only you can be the judge of that, because you know what > > was in that directory before you check your working copy > out. As per > > having to do use --force every time, I wouldn't think so. I > mean, you > > would need to make a judgement call if you already have a NotUsed > > directory, but if you do everytime, I would question why you do. I > > personally would check out a fresh new working copy in a non, yet, > > existing directory. > > > > G > > Sorry about the top post. I'm also active on another mailing > list regarding dovecot where you are *supposed* to top post. > Again maybe I should have RTFM'd! It's ok :-) Now you know > OK- I think I understand. What the directory had in it was a > copy of what I put into the repository; I hadn't made any > changes since it went it went in, so it should be fine. All > other directories similarly; so, if I understand correctly, > if I delete them all first or just use --force to check them > out, it should be the same. I'm not 100%. As I said I'm a bit uncomfortable in using the --force option. I'd rather check out in a new directory. G
Inconsistency between "svn list" and "svn checkout"
Hi, according to the documentation, the "svn list" command should "list each TARGET file and the contents of each TARGET directory as they exist in the repository." However I think this is not true for repositories with path-based authorization. I have a repository with various subdirectories at the root, each with different access rights defined by an authz file. A simplified example is presented in the following: repository +- 1_public +- 1.txt +- 2_secret +- 2.txt +- 3_public +- 3.txt The "1_public" and "3_public" subdirectories are readable by every authorized user. The access to "2_secret" is restricted to a certain group of users. When an "unprivileged" user performs an "svn list" on the repository, the following happens: > svn list --verbose --recursive svn://server/repository 1 user Sep 13 22:35 ./ 1 user Sep 13 22:35 1_public/ 1 user 123 Sep 13 22:35 1_public/1.txt 1 user Sep 13 22:35 2_secret/ svn: Authorization failed The process aborts at the first subdirectory that is not accessible by the respective user. However, when compared to what "svn checkout" does in the same situation, this seems inconsistent: > svn co svn://server/repository Atest\3_public Atest\3_public\3.txt Atest\1_public Atest\1_public\1.txt Checked out revision 1. I would expect "svn list" to work in very much the same way than "svn checkout", which means that it should continue to run and show me the contents of the "3_public" subdirectory. Is there a way to force "svn list" to do this? What I'm trying to do is to automatically calculate the size of the part of the repository a certain user has access to. However, this requires "svn list" to list all files, even if a subfolder is inaccessible, because "svn checkout" would omit it anyway. Even if there is another way to handle this, I would still vote for "svn list" becoming consistent to "svn checkout" for that matter. Thank you very much in advance for your suggestions! Tested with SlikSVN 1.6.12, but reproducible with many other older SVN clients as well. -- Michael Geisinger
Re: Inconsistency between "svn list" and "svn checkout"
Sidewinder_GER wrote on Mon, Sep 13, 2010 at 22:53:11 +0200: > When an "unprivileged" user performs an "svn list" on the repository, > the following happens: > >> svn list --verbose --recursive svn://server/repository > 1 user Sep 13 22:35 ./ > 1 user Sep 13 22:35 1_public/ > 1 user 123 Sep 13 22:35 1_public/1.txt > 1 user Sep 13 22:35 2_secret/ >svn: Authorization failed > > The process aborts at the first subdirectory that is not accessible by > the respective user. ... > I would expect "svn list" to work in very much the same way than "svn > checkout", which means that it should continue to run and show me the > contents of the "3_public" subdirectory. I agree. Could you please file an appropriate issue in our tracker (if there isn't one already)? FWIW, an easy way to reproduce this is: $svn ls -R http://svncorp.org/svncorp/svn/trunk .. subversion/svn/list-cmd.c:289 subversion/libsvn_client/list.c:272 subversion/libsvn_client/list.c:107 subversion/libsvn_client/list.c:73 ... svn: access to '/svncorp/svn/trunk/private' forbidden Which yields error SVN_ERR_RA_DAV_MALFORMED_DATA under ra_serf and error SVN_ERR_RA_DAV_FORBIDDEN under ra_neon. (I haven't tested ra_local and ra_svn.) Ideally, the fix for this issue will include making ra_serf return the latter (more specific) error code. Thanks! Daniel
Why does SVN prompt me for a password every time, after a domain migration?
A few days ago my login got moved from one Windows domain to another. I've had to deal with several problems as a result of that. One particular problem is having with SVN. For some reason SVN is prompting me for a password on every single operation it tries to do. This is tolerable in Eclipse (Subversive plugin), as I simply have to press Enter on the dialog each time, as it's preentered the name and password. However, it's worse from the command line. I can get it to work if I manually add "--password ..." to the command line. If I don't, the Cygwin Bash shell seems to get confused about how to handle the prompts. I have to use a non-Cygwin SVN. I never had to re-specify the password on every operation before the domain migration.
Re: Why does SVN prompt me for a password every time, after a domain migration?
Subversion caches that stuff in "%APPDATA%\Subversion", I believe in a file called 'auth'. Can't test right now because I'm not on a Windows system at the moment. Perhaps the owner did not get updated and the new domain can't write the the directory/file? You can look around there. Possibly just delete the directory/file - however, other options and passwords will go away -- be reset to the default. On Mon, Sep 13, 2010 at 15:36, KARR, DAVID (ATTSI) wrote: > A few days ago my login got moved from one Windows domain to another. > I've had to deal with several problems as a result of that. One > particular problem is having with SVN. For some reason SVN is prompting > me for a password on every single operation it tries to do. > > This is tolerable in Eclipse (Subversive plugin), as I simply have to > press Enter on the dialog each time, as it's preentered the name and > password. > > However, it's worse from the command line. I can get it to work if I > manually add "--password ..." to the command line. If I don't, the > Cygwin Bash shell seems to get confused about how to handle the prompts. > I have to use a non-Cygwin SVN. > > I never had to re-specify the password on every operation before the > domain migration. >
Re: Why does SVN prompt me for a password every time, after a domain migration?
On Windows, Subversion obtains configuration from the config files and the registry, both the user's specific parts and the "global" part. Possibly your new domain's global settings are to not cache passwords? Kevin Grover wrote on Mon, Sep 13, 2010 at 16:16:28 -0700: > Subversion caches that stuff in "%APPDATA%\Subversion", I believe in a > file called 'auth'. Can't test right now because I'm not on a > Windows system at the moment. Perhaps the owner did not get updated > and the new domain can't write the the directory/file? You can look > around there. Possibly just delete the directory/file - however, > other options and passwords will go away -- be reset to the default. > Removing the 'auth' directory kills cached passwords, cached server certificates, etc., but not "other options". > On Mon, Sep 13, 2010 at 15:36, KARR, DAVID (ATTSI) wrote: > > A few days ago my login got moved from one Windows domain to another. > > I've had to deal with several problems as a result of that. One > > particular problem is having with SVN. For some reason SVN is prompting > > me for a password on every single operation it tries to do. > > > > This is tolerable in Eclipse (Subversive plugin), as I simply have to > > press Enter on the dialog each time, as it's preentered the name and > > password. > > > > However, it's worse from the command line. I can get it to work if I > > manually add "--password ..." to the command line. If I don't, the > > Cygwin Bash shell seems to get confused about how to handle the prompts. > > I have to use a non-Cygwin SVN. > > > > I never had to re-specify the password on every operation before the > > domain migration. > >
Re: SVN performance issue
On Mon, Sep 13, 2010 at 8:40 AM, Sakshi Kaul wrote: > Hi, > > > > Greetings of the day! > > > > I have a repository of 20gb on SVN hosted on LINUX operating system but its > taking unusually long time to access it over rep browser. Which "rep browser" are you using? Which protocol, svn, http, https, ssh+svn, file, or what? Also, 20 Gig sounds a bit bulky. is this something you can split out gracefully? Have you been upgrading the repository from earlier releases without doing a "svnadmun dump" and "svnadmin load" to cleanly rebuild the repo? Is it Berkely DB based (gack!!!)? > > > > While the other repositories hosted on same box and with the same data size > are working fine. > > > > I tried a lot but could not zero down to this performance issue. > > > > It would be really helpful if someone helps me on this. > > > > Thanks, > > Sakshi > > > > This message contains information that may be privileged or confidential and > is the property of the KPIT Cummins Infosystems Ltd. It is intended only for > the person to whom it is addressed. If you are not the intended recipient, > you are not authorized to read, print, retain copy, disseminate, distribute, > or use this message or any part thereof. If you receive this message in > error, please notify the sender immediately and delete all copies of this > message. KPIT Cummins Infosystems Ltd. does not accept any liability for > virus infected mails.
Re: SVN performance issue
How is that repository different from the other repositories that work fine? Do you use path-based authorization? Can you rule out network issues? (i.e., try to access the server program via svn://localhost or http://localhost on the box) Sakshi Kaul wrote on Mon, Sep 13, 2010 at 18:10:07 +0530: > Hi, > > Greetings of the day! > > I have a repository of 20gb on SVN hosted on LINUX operating system but its > taking unusually long time to access it over rep browser. > > While the other repositories hosted on same box and with the same data size > are working fine. > > I tried a lot but could not zero down to this performance issue. > > It would be really helpful if someone helps me on this. > > Thanks, > Sakshi >
Re: check out log
> > Hi,Everybody > How to know Checkout log when access by svn:// . > Best Regards， > --Cody.Zhang >
