Re: Network Share Checkouts
On Sun, Nov 13, 2011 at 8:46 AM, Nico Kadel-Garcia wrote: [...] > No, it happens *every time* yous set it to "native" and wind up > editing code in one OS and running it in another. It's particularly a > problem when people use TortoiseSVN to a CIFS accessible for code or > documents that get run on a distinct OS. For scripting languages it's > particularly adventuresome. The replication and addition of a file > other than with 'svn copy' requires manual or semi-automated setting > of "svn:eol", or the new files will have a distinct configuraiton. > Then when you *change* them to match, diffs get complicated. > > The whole thing is better dealt with by following git's model. "Don't > touch the bytes once submitted, what comes out is byte-for-byte what > you put in". I can see uses for 'Id' and 'URL', but this end-of-line > confusion is just that far too often: confusion. As I said already in another thread: we have no problem at all with the eol-style=native feature. We are very happy with it. Of course, we don't use working copies shared accross different OS's. As long as you understand what you're going to get with this feature, I see no problem with it. Besides, it's easy to block use of this feature, just disallow setting the eol-style property in your pre-commit hook. Then you'll get the same byte-for-byte behavior as what you're advocating. -- Johan
Re: merge problem. impossible to revert deleted file
On Sat, Nov 12, 2011 at 06:53:54PM +0100, Gunnar Dalsnes wrote: > On 11.11.2011 16:51, Philip Martin wrote: > >You can't revert wc/D/f without reverting the replace of wc/D. > Does this mean it's not possible to merge if the same dir is created > both in trunk and in branch? Can the "replace" of the "duplicate" > dir be avoided somehow? If not, it would be nice with an option to > disable tree-conflict for dirs, just "accepting" existing dirs with > same name. The tree conflict cannot be avoided at present. Your suggestion to "disable tree conflicts for dirs" really boils down to one particular way of resolving the conflict. Someone else might prefer a different resolution. For instance, they might want to rename one of the dirs after the merge to have the two new directories side-by-side. For now, you will have to somehow resolve the conflict using svn commands. We are planning to add interactive resolution menus for tree conflicts. But there is still a lot of work to do before this will become reality. You're welcome to pitch in and help us out with development efforts towards this goal.
Re: svn copy doesn't honour "--quiet" in 1.7.1 ??
Philip Martin wrote on Fri, Nov 11, 2011 at 11:16:45 +: > "Zibetti Paolo" writes: > > > With Subversion version 1.6.x, I could add the "--quiet" switch to the > > "svn copy" command to suppress all output in case the command succeeds. > > > > With Subversion version 1.7.1 "svn copy --quiet ..." always prints > > informational messages such as "Committed revision 42." > > Other commands such as "svn commit", on the contrary, honour the > > "-quiet" switch as expected. > > > > Is this an intended behaviour or a bug ? > > That looks like an unintended change in behaviour. I don't see any > discussion around the time the change (r988627) was made. > This has been fixed on trunk and nominated for backport to 1.7.2.
Re: write-through-proxy and checksum error - URL path mangled in text data
Sebastian Brandt wrote on Fri, Nov 11, 2011 at 10:22:31 +0100: > How can I find out in which subversion releases the r878607, r916286 > and r1064734 are included? Use the 'svn mergeinfo' command on Subversion's repository: % U=http://svn.apache.org/repos/asf/subversion % svn mergeinfo --show-revs=eligible $U/trunk $U/branches/1.6.x | grep r1064734 They are included in the 1.7.x line: % $svn log --stop-on-copy -r 0:HEAD -l1 -q ^/subversion/branches/1.7.x r1145993 | hwright | 2011-07-13 16:12:22 +0300 (Wed, 13 Jul 2011)
SVN error 500 - possibly active directory related
Hello all, let me start by saying I'm basically fairly clueless about SVN. Someone else at my company maintains all the Linux servers and he is unavailable. I'm OK with Linux but resort to googling a lot. I'm on the windows side of the shop and last night we took the old domain controller permanently offline. We have a new DC in the same domain but with a new IP address. Note that the old DC was SBS2003, the new is Win2K8R2 (again, same domain, I added Win2K8R2 to the domain, moved all roles off SBS, then demoted SBS and took it offline) I got a complaint today that people could no longer log into SVN and as it turns out, it was integrated into AD. I googled a bunch, found this config file: /home/svn/apache_files/conf/auth.conf which contained these line (edited to remove identifying info) AuthType Basic AuthzLDAPAuthoritative off AuthLDAPURL "ldap://sbs.domain.local:389/DC=domain,DC=local?sAMAccountName?sub?(objectCategory=person)" AuthLDAPBindDN "ldapreader@domain.local" AuthLDAPBindPassword xx I changed the AuthLDAPURL to point to the new server (and pinged it to make sure it resolved and was reachable) Then I tested logging in. When I enter a bad password, error.log shows: [Sun Nov 13 15:33:43 2011] [error] [client 192.168.3.107] user robr: authentication failure for "/": Password Mismatch When I enter a good password nothing shows up in error.log, instead in access.log I see: 192.168.2.130 - robr [13/Nov/2011:16:42:52 -0500] "GET / HTTP/1.1" 500 772 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" and the browser shows: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. I don't see any login failure messages in the event log on the domain controller. What can I do next to troubleshoot this issue? Thanks much!!
Re: Network Share Checkouts
On Nov 13, 2011, at 01:46, Nico Kadel-Garcia wrote: > On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt wrote: >> >> On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote: >> >>> Windows versus UNIX style end-of-line also becomes important. The >>> "svn:eol" style for files in a shared repository will behave >>> differently on Windows boxes accessing a CIFS share from a UNIX or >>> Linux box via Samba than the UNIX or Linux box will provide with local >>> or NFS access to exactly the same working copy if that is set. >> >> >>> I spent a *lot* of time explaining this to verious people trying to >>> use multiple platform shared access, and running headlong into the >>> problems they thought they'd "cleverly" worked around. It became an >>> adventure to explain why svn:eol should be deprecated, preferably with >>> a claw hammer. >> >> Every time you bring this up I have to point out that what you're talking >> about applies only when a file's svn:eol-style property is set to "native". >> It does not apply when svn:eol-style is set to another value, such as "LF" >> or "CRLF", nor does it apply if svn:eol-style is not set. > > No, it happens *every time* yous set it to "native" and wind up > editing code in one OS and running it in another. [snip] ...right, that's what I said. There is a potential for unexpected problems of the kind you describe when you set svn:eol-style to native. But there is no problem when you set svn:eol-style to LF or CRLF. I was taking exception to your overgeneralization that "svn:eol [sic] should be deprecated"; it should not, because it works fine and serves a useful function.
working on multiple patches
Hi I finished working on a patch A and posted it to acceptation. I would like to keep this patch applied in my working copy and work on another patch B. I don't see any way to do this, except having my own svn repository. But with Mercurial it was easy: 1. Revert all 2. Apply patch A throuch command 'hg import'. 3. Subsequent diffs were not showing changes of A. Is Mercurial simply better in this case? Regards Jarek
