Re: Crash in IntelliJ Idea with "Merge from trunk"
Hello Salvi, > Version: 1.8.0 (r1490375), compiled Jun 16 2013, 22:47:58 You run an outdated SVN client version. Try SVN 1.8.19 or 1.9.7. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: Subversion version 1.6.11 (r934486) package
On Mon, Sep 25, 2017 at 12:32 AM, Branko Čibej wrote: > On 25.09.2017 02:50, Nico Kadel-Garcia wrote: >> On Sun, Sep 24, 2017 at 8:46 PM, Nico Kadel-Garcia wrote: >> >>> That published version is 1.9.3, but it actually has some upstream >>> support at RedHat. I've done personal builds, and used to publish to >>> RPMforge, and it's not worth the work. >> Sorry, I realized I was unclear. Unless you really enjoy unfurling the >> building of bleeding edge software, or someone is paying you for it, >> it's much safer and faster to get a tested build from your favorite >> upstream distributor, even if it's not the latest version. The switch >> from 1.9.3 to 1.9.7 would not, in my opinion. justify the work of >> taking this project on to build it locally if you have a day job. Been >> there, done that, have published hundreds of update RPM's, and unless >> you like to develop RPM's or handbuild software to feel empowered, >> it's not worth the work. > > So of course it's always worth taking a look at > > http://opensource.wandisco.com/centos/7/svn-1.9/ > > which does have 1.9.7. *True*. And I see that wandisco has chosen to make it a yum enabled repository, which is cool and makes updates easier. Unfortunately, it also includes upgrades and system replacements for "serf" and "mod_dav", which are requirements for the Subversion update but will replace Red Hat published versions of those components. That can make dependency handling tricky if you run other web services on the Subversion server.
RE: Subversion version 1.6.11 (r934486) package
Thank you, Nico! Fei Peng t: +1 519.620.7232 m: +1 519.497.9917 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com -Original Message- From: Nico Kadel-Garcia [mailto:nka...@gmail.com] Sent: Sunday, September 24, 2017 8:46 PM To: Fei Peng Cc: users@subversion.apache.org Subject: Re: Subversion version 1.6.11 (r934486) package On Fri, Sep 22, 2017 at 12:16 PM, Fei Peng wrote: > Hello, > > Can you please tell me where I can get Subversion version 1.6.11 > (r934486) package? I need to setup a 1.6.11 server on centos7, then > migrate our current svn 1.6.11 on centos5.6 to the 1.6.11 server on > centos7. Then upgrade the svn 1.6.11 server on centos7 to the current version > (1.9.7). Please don't You'll *really* hurt yourself having to support that. CentOS 7 has 1.7.x as its default Subversion. If you need Subversion 1.9, it's in the "SCLO" repository, such as the copy at http://scanmail.trustwave.com/?c=4062&d=19HI2cIm_KBXzn41RIkxVLPDAOCLqYhHRUGRETh4YA&s=5&u=http%3a%2f%2fmirrors%2ekernel%2eorg%2fcentos%2f7%2e4%2e1708%2fsclo%2fx86%5f64%2fsclo%2fsclo-subversion19%2f That published version is 1.9.3, but it actually has some upstream support at RedHat. I've done personal builds, and used to publish to RPMforge, and it's not worth the work. > I am not sure if I can install svn 1.9.7 on centos7 and migrate my svn > 1.6.1 directly to the 1.9.7 on centos7. Yes, you can. Definitely look into setting up an "svnmirror", to establish a new Subversion on your CentOS 7.x box slaved to the old one, and look at "svnadmin hotcopy" on the old server to get a copy of hte configs with your local tuning. We've discussed this before for people planning upgrades, and even discussed it in the lst week. When you're happy with the new mirror, *write lock* the old one, and help your users set their repositories to point to the new server. It's usually easier and safer if they actually check out new working copies, but not everyone is willing to do that. > Any advice will be highly appreciated and thank you in advance! > > > > Fei Peng > > > > t: +1 519.620.7232 > > m: +1 519.497.9917 > > > > Trustwave | SMART SECURITY ON DEMAND > > www.trustwave.com > >
Re: override global-ignores from server side
On Tue, Sep 19, 2017 at 4:21 PM, Branko Čibej wrote: > On 19.09.2017 11:02, Bert Huijben wrote: >> >>> -Original Message- >>> From: Balogh Péter [mailto:balogh.pe...@xcite.hu] >>> Sent: dinsdag 19 september 2017 10:59 >>> To: users@subversion.apache.org >>> Subject: Re: override global-ignores from server side >>> >>> Hi, >>> >>> Yes, I'm aware that adding the .a file manually is possible, but it does not >>> solve the issue, that we have to check manually after every library update, >>> if >>> a new .a file is added And the issue won't show up, until we commit the >>> changes, and the CI build fails with a linking error The default list is >>> not large, >>> that's why overriding it does not seem to be an irrational request But right >>> now, if I put a .a file in an SVN, I have no way to make it show up in the >>> status without client side modifications, and I think it's a really >>> important >>> missing feature >> Where I work we have a strict policy that we don't release binaries that are >> built on normal workstations, just those on regulated build systems where we >> can 100% reproduce previous builds. Having a default that would make users >> commit locally build artifacts would go against that. We manage these >> artifacts using different tooling that was designed for that purpose. > > Well frankly I was under the impression that svn:global-ignores overrode > the global-ignores client config setting. Apparently it does not ... I'd > call that a bug, but that's water under the bridge ... > > -- Brane Indeed, the designed behaviour (IIUC) was definitely that the repository-dictated configuration would take priority over the client's config setting [1] (except for command-line options, which take even higher priority, as discussed / clarified here: [2]). The OP has created a JIRA issue: https://issues.apache.org/jira/browse/SVN-4699 I'll add these references also to that issue. (Note to Peter Balogh: having the issue in JIRA does not mean it will be solved more quickly -- someone still needs to pick it up, investigate, discuss, and possibly come up with a patch -- any further help there is most welcome :-)) [1] https://wiki.apache.org/subversion/ServerDictatedConfiguration#Configuration_hierarchy [2] https://svn.haxx.se/dev/archive-2012-01/0210.shtml -- Johan
