Re: Merging Properties?
On Thu, Jun 09, 2011 at 07:58:12PM -0500, Brian Neal wrote: Hello, Suppose I have a file on trunk called file.txt. I put a property on it, say color with the value red. Now I copy trunk to a branch B. On branch B I change file.txt's color property to green. Now independently on trunk, I also change file.txt's color property to green. When I merge the branch B back to trunk, I get a merge conflict, even though both the branch and the trunk are trying to change the property to the same value. Is this expected or a bug or ...? How did you perform the merge? You generally need to use the --reintegrate option (or the equivalent in TortoiseSVN, 2nd choice in the merge dialog) to merge a branch back into trunk without conflicts. Also, are you really sure the property values are same? Maybe they differ in some subtle way, like line-ending style or other whitespace changes? Because, unfortunately, I cannot reproduce your problem from the description you've provided. The following script which I used to try to reproduce your problem runs fine, both with and without --reintegrate. There is no conflict during the merge. But not using --reintegrate here is wrong, see http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E #!/bin/sh set -e cwd=`pwd` basename=`basename $0` scratch_area=`echo $basename | sed -e s/\.sh$//` repos=$scratch_area/repos trunk=$scratch_area/trunk branch=$scratch_area/branch trunk_url=file:///$cwd/$repos/trunk branch_url=file:///$cwd/$repos/branch set -x rm -rf $scratch_area mkdir -p $scratch_area mkdir -p $trunk echo alpha $trunk/alpha echo beta $trunk/beta mkdir $trunk/gamma echo delta $trunk/gamma/delta mkdir $trunk/epsilon echo zeta $trunk/epsilon/zeta svnadmin create $cwd/$repos svn import $trunk $trunk_url -m importing project tree rm -rf $trunk svn checkout $trunk_url $trunk svn ps color red $trunk/alpha svn commit $trunk -m set color to red svn copy $trunk_url $branch_url -m creating branch svn checkout $branch_url $branch svn ps color green $trunk/alpha svn commit $trunk -m set color to green svn ps color green $branch/alpha svn commit $trunk -m set color to green svn update $trunk svn merge --reintegrate $branch_url $trunk svn diff $trunk
Re: Merging Properties?
On Fri, Jun 10, 2011 at 11:07 AM, Stefan Sperling s...@elego.de wrote: ... svn ps color green $branch/alpha svn commit $trunk -m set color to green Shouldn't the above be 'svn commit $branch ...'? -- Johan
Re: Merging Properties?
On Fri, Jun 10, 2011 at 11:16:44AM +0200, Johan Corveleyn wrote: On Fri, Jun 10, 2011 at 11:07 AM, Stefan Sperling s...@elego.de wrote: ... svn ps color green $branch/alpha svn commit $trunk -m set color to green Shouldn't the above be 'svn commit $branch ...'? Ooops, you're right, thanks for catching that! Yeah, with this change the script does indeed cause a spurious conflict, even in 1.7.
Re: Merging Properties?
On Fri, Jun 10, 2011 at 11:25:23AM +0200, Stefan Sperling wrote: On Fri, Jun 10, 2011 at 11:16:44AM +0200, Johan Corveleyn wrote: On Fri, Jun 10, 2011 at 11:07 AM, Stefan Sperling s...@elego.de wrote: ... svn ps color green $branch/alpha svn commit $trunk -m set color to green Shouldn't the above be 'svn commit $branch ...'? Ooops, you're right, thanks for catching that! Yeah, with this change the script does indeed cause a spurious conflict, even in 1.7. Filed http://subversion.tigris.org/issues/show_bug.cgi?id=3919
Sparse check outs
We use svn as a document management system. In our case we have different Roles in the same Project. We have Roles like Project Manager, Business Consultants and Technical Consultants. Each of them have their own kind of files they are interested in. My colleagues would like to sparse check out things based on some Rules like *pptx in a folder and its sub folders. Would like to ignore specific extensions like *c,*cpp,*txt. Much the same way as the ignore list for non versioned files, but just for co. Did somebody come along such a requirement? Regards Thomas
Re: Unretrievable file
On Thursday 09 June 2011, Bill Herring wrote: I have a problem that began when I mistakenly attempted to switch a file to an older tagged version. It instead converted my file into a folder containing the whole of the older tagged project. I tried to switch back but it would say “can’t replace a folder from within”. Bill, it would be helpful if you didn't start a new thread for the almost same issue, because that makes it impossible to tell if you actually read and understood the answers given. Note that people are not normally CCing people that write to mailinglist, so if you are not subscribed and you want a CC, you should say so. Secondly, if you told us exactly what you actually did, it would be possible to distinguish between a user error and a Subversion bug. I was advised to delete it and then update my working copy in order to restore my file and SVN back to a happy state. However this didn’t work. Each folder and file in a working copy maps to one location in the repository. This information is always stored in the _parent_ folder of that element, and it is that which you have to change. Deleting and updating works when you have changes made to the file or directory content, but not things like switched URLs or property changes. What you can do is delete the parent folder or you switch the file back, as suggested before. The situation now is that if I attempt almost any operation in the directory that contained the myOriginalFile, it tells me “the . . path (i.e. the directory ) is locked, use Cleanup”. But if I try to use Cleanup it says “error processing entry for myOriginalFile.c, myOriginalFile.c is already under version control”. What can I do to get back to normality? This seems as if SVN had gotten into a state it can't recover from without manual intervention. If so, the reason could be misuse or a bug, but there's not enough info to tell. I’m prepared to throw away the original file and start again with a new name but I just can’t seem to make SVN forget about it? Please help. You can always check out multiple working copies! You could throw away the whole working copy without loosing any history or files, except of course for those changes made inside the working copy which weren't committed yet. I wish you a nice weekend! Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
Re: Merging Properties?
On Fri, Jun 10, 2011 at 4:28 AM, Stefan Sperling s...@elego.de wrote: On Fri, Jun 10, 2011 at 11:25:23AM +0200, Stefan Sperling wrote: On Fri, Jun 10, 2011 at 11:16:44AM +0200, Johan Corveleyn wrote: On Fri, Jun 10, 2011 at 11:07 AM, Stefan Sperling s...@elego.de wrote: ... svn ps color green $branch/alpha svn commit $trunk -m set color to green Shouldn't the above be 'svn commit $branch ...'? Ooops, you're right, thanks for catching that! Yeah, with this change the script does indeed cause a spurious conflict, even in 1.7. Filed http://subversion.tigris.org/issues/show_bug.cgi?id=3919 Thank you Stefan for reproducing the issue with the script and reporting it as a bug. I'd be willing to try to work up a patch or help resolve the bug in any way. Just give me a bit of a nudge in the right direction. Best regards, BN
Re: Merging Properties?
On Fri, Jun 10, 2011 at 07:50:47AM -0500, Brian Neal wrote: On Fri, Jun 10, 2011 at 4:28 AM, Stefan Sperling s...@elego.de wrote: Filed http://subversion.tigris.org/issues/show_bug.cgi?id=3919 Thank you Stefan for reproducing the issue with the script and reporting it as a bug. I'd be willing to try to work up a patch or help resolve the bug in any way. Just give me a bit of a nudge in the right direction. The problem is probably somewhere in the function maybe_generate_propconflict() in subversion/libsvn_wc/props.c. I think it has been written with update in mind and makes wrong assumptions for merge. I haven't had enough time to dig in deeper. If you can figure it out, please send a patch :) Thanks!
Apache Subversion 1.7.0-alpha1 Released
I'm happy to announce Apache Subversion 1.7.0-alpha1, the first public pre-release of the 1.7.x series, is now available. Please choose the closest mirror to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: 7710d703eb2365b2e91d66cedc4dbaab4ef6fbea subversion-1.7.0-alpha1.tar.bz2 212eaca54374a8e95ab5c6a15208870bbb339ae6 subversion-1.7.0-alpha1.tar.gz bddc417433732ed09b8e641cc08ef49850574d36 subversion-1.7.0-alpha1.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.0-alpha1.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.0-alpha1.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.0-alpha1.zip.asc For this release, the following people have provided PGP signatures: Senthil Kumaran S [1024D/6CCD4038] with fingerprint: 8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038 Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C This is the first public release for what will eventually become Apache Subversion 1.7.0. It contains several known issues, a complete list of 1.7.0-blocking issues can be found here: http://subversion.tigris.org/issues/buglist.cgi?component=subversionissue_status=NEWissue_status=STARTEDissue_status=REOPENEDtarget_milestone=1.7.0 The term 'alpha' means the Subversion developers feel that this release is ready for widespread testing by the community. There are known issues (and unknown ones!), so please use it at your own risk, though we do encourage people to test this release thoroughly. As a note to operating system distro packagers: while we wish to have this alpha widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a alpha poses many problems, the biggest being that our policy lets us break compatibility between the alpha and the final release, if we find something serious enough. Having many users depending on an alpha through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the alpha there. Just don't let it near the end users please. Please note that due to various improvements made to the working copy library, the working copy format has changed. You must explicitly upgrade your working copy by running 'svn upgrade'. After doing so, the working copy will no longer be usable by earlier versions of Subversion. Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.0-alpha1 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.0-alpha1/CHANGES These documents are currently incomplete, but will be completed as we move toward a final release. Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Fwd: svn problems
Dear Subversion experts, I have really a proxy/firewall problem using svn to download a package I use it for research. I am listing here the error message after using svn to download the software from the site here below: *** svn: OPTIONS of 'https://ekpbelle2.physik.uni-karlsruhe.de:/trunk/tools': Could not create SSL connection through proxy server: Could not authenticate to proxy server: ignored Kerberos challenge, ignored NTLM challenge, GSSAPI authentication error: Unspecified GSS failure. Minor code may provide more information: No credentials cache found (https://ekpbelle2.physik.uni-karlsruhe.de) * My institute is using proxy on port 8080 and I was in contact with the administrator but he did not solve the problem. I set the proxy and password on the subversion servers config file: /etc/subversion/servers but is still does not work. The administrator removed all firewalls on a port (3690) so I used: svn co https://ekpbelle2.physik.uni-karlsruhe.de:3690/trunk/tools and it did not work Would you like please answer me: It is important for me. Thank you rachid ayad
Re: svn problems
On Jun 10, 2011, at 12:27, rachid ayad wrote: Dear Subversion experts, I have really a proxy/firewall problem using svn to download a package I use it for research. I am listing here the error message after using svn to download the software from the site here below: *** svn: OPTIONS of 'https://ekpbelle2.physik.uni-karlsruhe.de:/trunk/tools': Could not create SSL connection through proxy server: Could not authenticate to proxy server: ignored Kerberos challenge, ignored NTLM challenge, GSSAPI authentication error: Unspecified GSS failure. Minor code may provide more information: No credentials cache found (https://ekpbelle2.physik.uni-karlsruhe.de) * My institute is using proxy on port 8080 and I was in contact with the administrator but he did not solve the problem. I set the proxy and password on the subversion servers config file: /etc/subversion/servers but is still does not work. The administrator removed all firewalls on a port (3690) so I used: svn co https://ekpbelle2.physik.uni-karlsruhe.de:3690/trunk/tools and it did not work I'm afraid I don't know the answer to your question, I just want to point out that 3690 is the default port for svnserve, so that's applicable when a repository is served using the svn:// protocol, which this repository is not: it's served with the https:// protocol, which means it by default uses port 443. You cannot simply pick a different port number to communicate with a server with, unless that server is configured to respond with the correct protocol on that port; this server does not appear to be configured to respond at all on port 3690, which is not a surprise. When I try svn ls https://ekpbelle2.physik.uni-karlsruhe.de/trunk/tools; I first get asked if I want to accept the SSL certificate, and when I accept it temporarily, I'm then prompted for my username and password; when I fail that because I don't have one, I get svn: OPTIONS of 'https://ekpbelle2.physik.uni-karlsruhe.de/trunk/tools': authorization failed: Could not authenticate to server: rejected Basic challenge (https://ekpbelle2.physik.uni-karlsruhe.de). You are presumably entering a valid username and password before receiving the error you mentioned above? Or does it show that before even asking you for a username and password?
Index of Subversion add-on projects and products
Hi All, I was wondering if there is some sort of global list of Subversion plug-ins, etc., including both open source projects and commercial products. For example, it would be nice if there was a unified list of all the different svn clients, integrations with build systems, etc. Thanks for any suggestions. - Kevin
Subversion 1.6 on Ubuntu Server 11.x
I posted about this on the Ubuntu forums but thus far nobody has replied. When SSH'd into the box and using svn operations, I'm getting the dastardly warning about my password is going to get stored to disk unencrypted. I read about Subversion 1.6 security changeshttp://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/ . I read about Subversion 1.6 on Ubuntu Server over at superuser.comhttp://superuser.com/questions/186575/whats-the-best-way-to-store-an-encrypted-svn-password-on-ubuntu-server . I read about gnome-keyring over at stackoverflowhttp://stackoverflow.com/questions/3824513/svn-encrypted-password-store . I've been doing a lot of reading on it. I have done the following: * installed gnome-keyring *edited my ~/.subversion/config to turn password-stores = gnome-keyring edited my ~/.subversion/servers to store-passwords = yes store-plaintext-passwords = no Thing is, I'm not using any GUI so it's still not working. Should I try encfs ? I read another post about a tool from CollabNet called keyring_tool but I don't have it on this system. Where do I get that? I've never run into these issues before (new distro, new svn version). Any additional insight would be very much appreciated.
Re: svn problems
Thank you Ryan for your answer, I think is before the host password (is since weeks I had this problem so I will try from my office) with my home network it works fine with the host password. But it's a good question because! is the authentification the message talks about, is from the proxy or the host? I think the message is clear it says could not authenticate to proxy server. Also I inform you that when I do not specify the proxy id and password in subversion servers config file svn hangs and when I specify it it will not hang but immediately displays the error message below. thank you, rachid On Sat, Jun 11, 2011 at 12:59 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: On Jun 10, 2011, at 12:27, rachid ayad wrote: Dear Subversion experts, I have really a proxy/firewall problem using svn to download a package I use it for research. I am listing here the error message after using svn to download the software from the site here below: *** svn: OPTIONS of 'https://ekpbelle2.physik.uni-karlsruhe.de:/trunk/tools': Could not create SSL connection through proxy server: Could not authenticate to proxy server: ignored Kerberos challenge, ignored NTLM challenge, GSSAPI authentication error: Unspecified GSS failure. Minor code may provide more information: No credentials cache found (https://ekpbelle2.physik.uni-karlsruhe.de) * My institute is using proxy on port 8080 and I was in contact with the administrator but he did not solve the problem. I set the proxy and password on the subversion servers config file: /etc/subversion/servers but is still does not work. The administrator removed all firewalls on a port (3690) so I used: svn co https://ekpbelle2.physik.uni-karlsruhe.de:3690/trunk/tools and it did not work I'm afraid I don't know the answer to your question, I just want to point out that 3690 is the default port for svnserve, so that's applicable when a repository is served using the svn:// protocol, which this repository is not: it's served with the https:// protocol, which means it by default uses port 443. You cannot simply pick a different port number to communicate with a server with, unless that server is configured to respond with the correct protocol on that port; this server does not appear to be configured to respond at all on port 3690, which is not a surprise. When I try svn ls https://ekpbelle2.physik.uni-karlsruhe.de/trunk/tools; I first get asked if I want to accept the SSL certificate, and when I accept it temporarily, I'm then prompted for my username and password; when I fail that because I don't have one, I get svn: OPTIONS of ' https://ekpbelle2.physik.uni-karlsruhe.de/trunk/tools': authorization failed: Could not authenticate to server: rejected Basic challenge ( https://ekpbelle2.physik.uni-karlsruhe.de). You are presumably entering a valid username and password before receiving the error you mentioned above? Or does it show that before even asking you for a username and password?
Re: Index of Subversion add-on projects and products
On Jun 10, 2011, at 17:09, k...@timpanisoftware.com k...@timpanisoftware.com wrote: I was wondering if there is some sort of global list of Subversion plug-ins, etc., including both open source projects and commercial products. For example, it would be nice if there was a unified list of all the different svn clients, integrations with build systems, etc. The Subversion project used to maintain such a list but it became unwieldy and was deleted. They now recommend you use Google to find such things. You can still find the last version of this list in the 1.6.x branch but it is gone from trunk: http://svn.apache.org/repos/asf/subversion/branches/1.6.x/www/links.html
RE: Subversion 1.6 on Ubuntu Server 11.x
From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com] Sent: Friday, June 10, 2011 3:26 PM To: users@subversion.apache.org Subject: Subversion 1.6 on Ubuntu Server 11.x I posted about this on the Ubuntu forums but thus far nobody has replied. When SSH'd into the box and using svn operations, I'm getting the dastardly warning about my password is going to get stored to disk unencrypted. I read about Subversion 1.6 security changeshttp://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/. I read about Subversion 1.6 on Ubuntu Server over at superuser.comhttp://superuser.com/questions/186575/whats-the-best-way-to-store-an-encrypted-svn-password-on-ubuntu-server. I read about gnome-keyring over at stackoverflowhttp://stackoverflow.com/questions/3824513/svn-encrypted-password-store. I've been doing a lot of reading on it. I have done the following: * installed gnome-keyring *edited my ~/.subversion/config to turn password-stores = gnome-keyring edited my ~/.subversion/servers to store-passwords = yes store-plaintext-passwords = no Thing is, I'm not using any GUI so it's still not working. Should I try encfs ? I read another post about a tool from CollabNet called keyring_tool but I don't have it on this system. Where do I get that? I've never run into these issues before (new distro, new svn version). Any additional insight would be very much appreciated. You also have to run the gnome-keyring-daemon. Most of the docs assume you do it from a GUI, but you don't have to. Just set up some shell login script to start one (per user) if it is not running, and re-use the same environment variable values if it is already running. This site will give you some hints, but the exercise is left to the reader. http://live.gnome.org/GnomeKeyring/RunningDaemon You do need to initialize your keyring, which is what the Collabnet keyring_tool is for. -Steve
