Re: Continuous Integration
I wish to create a web app and share it on SVN. I wish to use this SVN url for Jenkins Integration. I use Jenkins with SVN and it works just fine. You'll need the SVN plugin which is easily obtained through Jenkins. Do I need to take any precautions. For SVN, make sure it's configured for https:// and not http, unless it's internal. For Jenkins, make sure you enable security. By default it allows for anonymous read/write. You should also configure it for https rather than http, unless it's internal. Let me know if you have any specific questions. On Tue, Nov 19, 2013 at 9:14 PM, Ryan Schmidt subversion-20...@ryandesign.com wrote: On Nov 18, 2013, at 06:37, Navindian wrote: I wish to create a web app and share it on SVN. I wish to use this SVN url for Jenkins Integration. Do I need to take any precautions. I don’t understand the question. I use Subversion and I’ve develop web sites whose code I’ve stored in a Subversion repository, but I haven’t used Jenkins. Perhaps you could explain what role you want Jenkins to play, and why you think it will be a problem.
Re: SVN Blame Returns Corrupt Data
On Thu, Oct 10, 2013 at 5:49 PM, Bob Archer bob.arc...@amsi.com wrote: I assume he was asking how to fix the blame. Cause, sure, he could open the file, convert it back to UTF-8 with CRLF line endings... and commit it... of course, now blame is going to show him on every line, since he just changed every line. That's exactly what I meant. You're correct with how the blame is handled. I committed the UTF-8 copy to a test branch, diff'd, and it showed every line as being changed. Unfortunately it looks like this is our best option. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: At current blame is not UTF-16 aware. About a year ago there was a patch (actually they just reposted an entire copy of blame.c) posted that helped, but it really didn't go anywhere since the original poster didn't continue following up. Perhaps you'll find the above useful. Patches are of course welcome. I'll take a look at that this weekend. Thanks for all the input everyone. On Thu, Oct 10, 2013 at 7:07 PM, Ben Reser b...@reser.org wrote: On 10/10/13 12:17 PM, T.J. Perovich wrote: On Thu, Oct 10, 2013 at 2:27 PM, Ryan Schmidt subversion-20...@ryandesign.com mailto:subversion-20...@ryandesign.com wrote: Sounds like you've converted the file from UTF-8 to UTF-16. Thanks, you're absolutely right. It changed from UTF-8 to UTF-16LE. Any idea how to go about fixing it elegantly? We have about 3 months of commits since this happened. Diff's in the GUIs have been working fine and we don't blame too often which is why it was never noticed. At current blame is not UTF-16 aware. About a year ago there was a patch (actually they just reposted an entire copy of blame.c) posted that helped, but it really didn't go anywhere since the original poster didn't continue following up. https://mail-archives.apache.org/mod_mbox/subversion-dev/201207.mbox/%3CCAAF0CB13B282344AF95AD2DE3D1962215627A3C%40DAG-B.nexon.corp%3E and the followup https://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3ccab84ubvvrhffqyea5pf5gstmpxz+rh2jkvdvcqscocjv+rq...@mail.gmail.com%3E Perhaps you'll find the above useful. Patches are of course welcome.
SVN Blame Returns Corrupt Data
I'm having trouble running svn blame on a particular file. It's returning garbage. In TortoiseBlame: 3341 TJP ÿþO 3341 TJP In the command line: 3341TJP ■O 3341TJP The file is 10.1k lines, not 2. If I run the blame from revision 0 to 3341 it returns the correct information. In WinMerge and TortoiseMerge, diffing the files shows about 10 lines changing between 3340 and 3341 (it was merge). However, the command line diff shows the entire contents being changed with spaces between every character. So End Class reads E n d C l a s s, etc.. Diffing a merge post-rev# 3341 show the same spaces between every letter. svn diff -r 3341:3489 svn://... @@ -20032,7 +20058,7 @@ F i l l _ d d l L o c a t i o n ( ) F i l l _ d d l C o u n t r y ( ) Another strange thing is it's marking these as lines 20,032 and 20,058. But in Notepad++ they are lines 10,026 and 10,031. The line numbers in pre-rev# 3341 diffs match up between the Notepad++ and command line fine. Any ideas on what happened or how to fix it? I'm most concerned about getting the blame working again. Please let me know if you need more information or if I was unclear with anything. Thanks in advance!
Re: SVN Blame Returns Corrupt Data
On Thu, Oct 10, 2013 at 2:27 PM, Ryan Schmidt subversion-20...@ryandesign.com wrote: Sounds like you've converted the file from UTF-8 to UTF-16. Thanks, you're absolutely right. It changed from UTF-8 to UTF-16LE. Any idea how to go about fixing it elegantly? We have about 3 months of commits since this happened. Diff's in the GUIs have been working fine and we don't blame too often which is why it was never noticed. On Thu, Oct 10, 2013 at 3:15 PM, Bob Archer bob.arc...@amsi.com wrote: On Oct 10, 2013, at 11:29, T.J. Perovich tjperov...@gmail.com wrote: I'm having trouble running svn blame on a particular file. It's returning garbage. In TortoiseBlame: 3341 TJP ÿþO 3341 TJP In the command line: 3341TJP ■O 3341TJP The file is 10.1k lines, not 2. If I run the blame from revision 0 to 3341 it returns the correct information. In WinMerge and TortoiseMerge, diffing the files shows about 10 lines changing between 3340 and 3341 (it was merge). However, the command line diff shows the entire contents being changed with spaces between every character. So End Class reads E n d C l a s s, etc.. Diffing a merge post-rev# 3341 show the same spaces between every letter. svn diff -r 3341:3489 svn://... @@ -20032,7 +20058,7 @@ F i l l _ d d l L o c a t i o n ( ) F i l l _ d d l C o u n t r y ( ) Sounds like you've converted the file from UTF-8 to UTF-16. Another strange thing is it's marking these as lines 20,032 and 20,058. But in Notepad++ they are lines 10,026 and 10,031. The line numbers in pre-rev# 3341 diffs match up between the Notepad++ and command line fine. Sounds like the line endings changed as well. Sigh... if only svn would support Unicode encodings. BOb
