Re: Slow initial repo access (https method)
Hi, Just to let everyone know that the problem turned out to be that SSL applications on Windows (the TortoiseSVN client in our case) lookup www.download.windowsupdate.com to get updates to the certificate revocation list. See http://support.microsoft.com/kb/317541 We operate in an environment with no direct internet access (proxy only) so this request failed and made a 15 second pause on every connection. regards Matthew J Fletcher ** Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company registered in England Reg. No. 4353634 Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437 Web: www.serck-controls.com Admin: p...@serck-controls.co.uk A subsidiary of Schneider Electric. ** This email and files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the above. Any views or opinions presented are those of the author and do not necessarily represent those of Serck Controls Ltd. This message has been scanned for malware by Mailcontrol. www.Mailcontrol.com
Re: Error with svn diff
On Apr 27, 2011, at 20:06, Tony Butt wrote: > On Wed, 2011-04-27 at 02:05 -0500, Ryan Schmidt wrote: >> Do educate on which files should have svn:eol-style set to what value, and >> do encourage developers to use auto-props to automate what they learned, but >> also install a pre-commit hook script in the repository that absolutely >> prevents the problem from happening in the future. If you've decided for >> example that .txt files shall have the svn:eol-style set to native, then >> write and install a pre-commit hook script that prevents anyone from adding >> any .txt file that does not have svn:eol-style set to native. >> > > Do you know offhand of a similar script to require particular > properties? It seems that there should be a generic pre-commit script that would prevent any commit that doesn't match the properties specified in the autoprops section of a given config file. But I don't know where that script might be.
Re: Merging two projects in two different repos
On Thursday 28 April 2011, List Man wrote: > I want to take one project from one repo and put it in a directory under > another repo. Is it possible to keep the history of said project? No, not through the client interface, which is what you use for everyday work. If you have direct access to the repository, you could use e.g. the dumpfilter tool to change history retrospectively. Cheers! Uli -- ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html FAQ: http://subversion.apache.org/faq.html Docs: http://svnbook.red-bean.com/ ** 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: Windows SSL Error
Ok, then I'm out of ideas. Maybe someone else still has some suggestions? Johan On Wed, Apr 27, 2011 at 1:12 PM, Platz, Steve wrote: > Same thing there as well. > > -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Tuesday, April 26, 2011 4:15 PM > To: Platz, Steve > Cc: users@subversion.apache.org > Subject: Re: Windows SSL Error > > And what about the system-wide file then? /etc/subversion/servers? > > On Tue, Apr 26, 2011 at 9:53 PM, Platz, Steve wrote: >> For those Linux servers that I've tried this on, the ~/.subversion/servers >> file is the default one that is created with a brand new install. There are >> no entries under [global] or [groups]. >> >> -Original Message- >> From: Johan Corveleyn [mailto:jcor...@gmail.com] >> Sent: Tuesday, April 26, 2011 3:49 PM >> To: Platz, Steve >> Cc: users@subversion.apache.org >> Subject: Re: Windows SSL Error >> >> On Tue, Apr 26, 2011 at 6:06 PM, Platz, Steve wrote: >>> Our Entrust SSL certificate recently expired and was replaced with a >>> new one utilizing a certificate chain. Since installing the new >>> certificate, access to a front-end website using this same certificate has >>> been unaffected. >>> However, we're now seeing issues when we attempt to check >>> out/update/browse/etc the repository using Windows (XP/7). In >>> Windows, using version 1.6.16, I'm getting the following error: >>> >>> >>> >>> C:\Users\steve_platz>svn info >>> https://path/to/repository >>> >>> Error validating server certificate for 'https://path/to/repository:443': >>> >>> - The certificate is not issued by a trusted authority. Use the >>> fingerprint to validate the certificate manually! >>> >>> Certificate information: >>> >>> - Hostname: my.website.com >>> >>> - Valid: from Mon, 18 Apr 2011 18:52:34 GMT until Fri, >>> 05 Jun >>> 2015 23:15:02 GMT >>> >>> >>> >>> - Issuer: (c) 2009 Entrust, Inc., www.entrust.net/rpa >>> is incorporated by reference, Entrust, Inc., US >>> >>> - Fingerprint: >>> 96:b4:fa:19:bd:4a:ec:c2:bc:19:33:b8:25:2a:0a:47:28:41:07:d0 >>> >>> (R)eject, accept (t)emporarily or accept (p)ermanently? T >>> >>> >>> >>> Running the above (svn info) from a Linux machine works as you would >>> expect it to, without certificate errors. Is this a bug with the >>> Windows client or have I set something up incorrectly? >> >> Just guessing, but maybe the Linux machine (only your account, or >> system-wide) has been configured to trust the Issuer's certificate as a >> trusted certificate authority (thus automatically trusting every certificate >> issued by that CA), and your Windows machine hasn't. >> >> This can be configured on the client side, with the property >> ssl-authority-files >> - For the user in ~/.subversion/servers >> - System-wide in /etc/subversion/servers >> >> See for more info: >> http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn. >> advanced.confarea.opts.servers >> >> You can do the same on Windows (also system-wide, I think that only works >> via the Registry, but see the book for more details). >> >> HTH, >> -- >> Johan >> > > > > -- > Johan > -- Johan
Re: Merging two projects in two different repos
On Apr 28, 2011, at 05:27, Ulrich Eckhardt wrote: > On Thursday 28 April 2011, List Man wrote: >> I want to take one project from one repo and put it in a directory under >> another repo. Is it possible to keep the history of said project? > > No, not through the client interface, which is what you use for everyday work. > > If you have direct access to the repository, you could use e.g. the > dumpfilter > tool to change history retrospectively. That is to say, you can "svnadmin dump" the repo that contains the project now, "svndumpfilter" the dumpfile to extract only that project, and then "svnadmin load" it into the new repository. If you don't have access to the old repository, you can "svnsync" the old repository to a new empty repository on your machine, then "svnadmin dump" that. Loading the project into the new repository will probably destroy your ability to use dates as revisions in the new repository, because revisions will probably no longer be chronological. To work around that, you can dump the new repository too, and use svndumptool to merge the two dumpfiles with revisions interleaved in chronological order. This will renumber your old revisions though, and everyone will have to check out new working copies of the new repository, and you may not like either of those consequences either.
Re: Merging two projects in two different repos
Ulrich Eckhardt wrote on Thu, Apr 28, 2011 at 12:27:07 +0200: > On Thursday 28 April 2011, List Man wrote: > > I want to take one project from one repo and put it in a directory under > > another repo. Is it possible to keep the history of said project? > > No, not through the client interface, which is what you use for everyday work. > *cough* svnsync? > If you have direct access to the repository, you could use e.g. the > dumpfilter > tool to change history retrospectively. > > > Cheers! > > Uli > > > -- > ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html > FAQ: http://subversion.apache.org/faq.html > Docs: http://svnbook.red-bean.com/ > > ** > 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: How can I setup two svnservers with svnsync and both should provide checkout and checkins
On Thu, Apr 28, 2011 at 5:10 AM, Nico Kadel-Garcia wrote: > According to the paper, you *are*. You're mirring the backend > Subversion databases on the multiple servers, keeping them > synchronized by accepting only authorized transactions on a designated > "master" and relaying them to the other available servers as > necessary. That's actually master/slave behind the scenes: the slaves > effectively passthrough the database submissions. This is built into > every major multiple location database or service for the last I > dunno, 30 years? It's certainly fundamental to dynamic DNS and NTP > configurations. > > Mirroring a filesystem is a very different replication technique to the one WANdisco employs. WANdisco replays every write command that the client sends to their local node against the other Subversion front-ends, just as the client sent it. This happens after obtaining an agreement, but before the transaction reaches Subversion. We're not mirroring the backend of Subversion although the effect is the same in that each Subversion repository remains identical after the identical changes are applied. In a majority quorum there is NO master server - I'm not sure how you're reading the whitepaper, but behind the scenes or not there isn't any master being defined (although it is an option if people choose it - See Singleton Quorum). There is the concept of a 'distinguished' node which can act as a tie breaker in the event of a 50/50 split in the agreement, but the situations where that's invoked are pretty rare unless you only have two nodes to start with. > You've renamed the categories of service, but that's clearly the > underlying techonology. > As I say, I beg to differ here. I'm happy to keep discussing, but it might be quicker if you let me just show you on a real live platform. I'm open for that if you have time? Right. Now make it 3 sets of 3, with each set distributed in different > locations. *In each location*, the set of 3 can vote amongst > themselves and go haring off in divergence from the other 6, or even > two other sets of 3. Unless you prescribe that each distrubed set must > vote among all *9* servers, and get a majority, Yes, we prescribe 9 nodes here. There is no option for local agreement. If you have 9 nodes *in the same replication group* then the majority quorum is between all of them. You need 5 nodes to agree on a transaction for a global sequence number to be generated and the transaction allowed. You can run multiple replication groups for more complex requirements, but I think thats way outside the scope of this discussion. you're in danger of > local sets diverging. And when some idiot in a data center says "huh, > we're disconnected from the main codeline, we need to keep working, > it's active-active, we'll just set our local master and resolve it > later".. And until the connectivity is re-established, any cluster > chopped off is otherwise read-only. The can commit *nothing*. > > Users at a node which can't get an agreement for their commit can't commit. That's a lot better than if they are using a remote server and lose the connection, at which point they can neither read or write. WANdisco users get a clear message in the event they try to commit when a quorum isn't available. The part I take issue with here is the idiot at the datacentre. The fact is that people don't invest in a solution like WANdisco and then allow idiots in datacentres free access to the server to break the replication group. Not to mention that's it's deliberately not an easy process to perform (see http://docs.wandisco.com/svn/ms/v4.0/#T26 ). Even worse: Unless you have a designated master cluster, losing the > client clusters means the company's core Subversion services at their > main office are read-only if the network connections to enough remote > clusters break. There are environments where this is acceptable, but > if I ever installed a source control system that went offline at the > main offices because we lost overseas or co-location connections, > *which happens when someone mucks up the main firewall in the > corporate offices!!!*, they'd fire me without blinking the first time > it happened. > It's a scenario that can be easily planned for. Often the main site will have multiple local nodes (maybe with a load balancer in front for high availability) so that a quorum can still be reached should the link fail. In other scenarios people choose different quorum options to match their requirements. I've not come across a situation yet where a whiteboard and a little bit of forward thinking can't deal with any proposed scenario people want to throw at us. Of course we don't pretend to change the laws of physics. All of your global datacentres and Subversion replicas spontaneously combusted? Maybe now it's time to find that backup tape... Until some idiot resets the quorum targre list locally. That's not a > software protection, it's a procedural one. > In rea
RE: Trying (failing) to limit access to one user
> > Perhaps > > > > [/] > > ~jon = rw > > Nope. jon still able to check out the entire repository tree. > > So far, it seems that the only rules that make any difference are > "* =" > and "$authenticated =". These give everybody access. Without one of > these present, nobody has access. And now I can add "~anyname =" to > that > list. > > Using "anyname =" doesn't seem to have any effect at all on access. > It > certainly doesn't grant any access to anyname. > > This is why I mentioned in my OP that I thought this might be me > misunderstanding the meaning of "anonymous access" in this context. What authentication method are you using? I'm guessing while *= works but "jon=" (or other user names) doesn't that isn't the full user name that svn sees. If you look at your log are the usernames the ones you are expecting and putting into the authz file? BOb
Re: repo on Windows -- why not?
> are there any arguments to prefer Windows? (beside arguments that you drive > a Windows shop) > ok, looks like I have to adjust the section a bit. It's also very important to integrate Subversion seamlessly with Active Directory and other existing Windows infrastructure (it applies to Windows shops, of course). For example, products like VisualSVN Server allows users to authenticate in Subversion server via Integrated Windows Authentication (formerly known as NTLM authentication). This brings clear benefits such as Single Sign-On and two-factor authentication. Also please note that native Active Directory users and groups can be used to configure access permissions. There are other advantages such as integration with Windows Event Log and so on. -- With best regards, Danil Shopyrin VisualSVN Team
Re: repo on Windows -- why not?
On 4/28/11 9:42 AM, Danil Shopyrin wrote: are there any arguments to prefer Windows? (beside arguments that you drive a Windows shop) ok, looks like I have to adjust the section a bit. It's also very important to integrate Subversion seamlessly with Active Directory and other existing Windows infrastructure (it applies to Windows shops, of course). Just to add a bit to this, if one has Active Directory but uses Unix servers, one doesn't have to deploy on Windows to authenticate, can use LDAP in httpd to authenticate against AD. Blair
svn log -g inconsistent after merging a subtree separately
[ Please CC: me since I am not subscribed to the list. Thank you. ] Hi, I'd like to report what I think is a yet another bug in SVN 1.6.16. (Seems that SVN bugs are currently liking me...) I reproduced it both with the command line client and with TortoiseSVN for Windows. When you have two branches and regularly merge files from one branch to another, you can either merge them on the whole branch (mergeinfo will be written there) or on a subfolder (which puts the mergeinfo on the subfolder). In case you have files changed in a subfolder by a merge you did on the whole branch, and anyone on your team merges *one* change on that branch to that subfolder only, that branch shows *all* merges that were made in this folder (which were several hundreds) in the merge history for that revision. I attached a dump of a simple repository containing 2 changes on trunk which are individually merged to the branch. The second merge was performed on the subfolder and its revision history is broken. (Not a big deal in this small example, but a big deal in our "live" repository). Regards, Michael SVN-fs-dump-format-version: 2 UUID: bbee442e-a645-d94c-8f53-99f3948855a1 Revision-number: 0 Prop-content-length: 56 Content-length: 56 K 8 svn:date V 27 2011-04-28T17:49:06.515625Z PROPS-END Revision-number: 1 Prop-content-length: 114 Content-length: 114 K 7 svn:log V 14 Initial commit K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:50:16.078125Z PROPS-END Node-path: branches Node-kind: dir Node-action: add Prop-content-length: 10 Content-length: 10 PROPS-END Node-path: trunk Node-kind: dir Node-action: add Prop-content-length: 10 Content-length: 10 PROPS-END Node-path: trunk/dir Node-kind: dir Node-action: add Prop-content-length: 10 Content-length: 10 PROPS-END Node-path: trunk/dir/file.txt Node-kind: file Node-action: add Prop-content-length: 10 Text-content-length: 25 Text-content-md5: 4f331c97c5e6214eb0cfefd47a818b74 Text-content-sha1: 619d37214d20ed306dfd9222b14006802ea3bbc6 Content-length: 35 PROPS-END One To Three For Five Revision-number: 2 Prop-content-length: 113 Content-length: 113 K 7 svn:log V 13 Create branch K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:50:32.796875Z PROPS-END Node-path: branches/branch1 Node-kind: dir Node-action: add Node-copyfrom-rev: 1 Node-copyfrom-path: trunk Revision-number: 3 Prop-content-length: 114 Content-length: 114 K 7 svn:log V 14 fix first typo K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:50:59.984375Z PROPS-END Node-path: trunk/dir/file.txt Node-kind: file Node-action: change Text-content-length: 26 Text-content-md5: 337555ea26dbf2b37a0d5df7f0677525 Text-content-sha1: 094392cfddae63e113de72f342ff2df1c6472db3 Content-length: 26 One Two Three For Five Revision-number: 4 Prop-content-length: 115 Content-length: 115 K 7 svn:log V 15 Fix second typo K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:51:20.984375Z PROPS-END Node-path: trunk/dir/file.txt Node-kind: file Node-action: change Text-content-length: 27 Text-content-md5: b7427b1a57551e6b5535a313214ebc1d Text-content-sha1: 42ab6c99f82597ca9cf326b33bad8326bb52e507 Content-length: 27 One Two Three Four Five Revision-number: 5 Prop-content-length: 116 Content-length: 116 K 7 svn:log V 16 merge first typo K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:52:41.078125Z PROPS-END Node-path: branches/branch1 Node-kind: dir Node-action: change Prop-content-length: 42 Content-length: 42 K 13 svn:mergeinfo V 8 /trunk:3 PROPS-END Node-path: branches/branch1/dir/file.txt Node-kind: file Node-action: change Text-content-length: 26 Text-content-md5: 337555ea26dbf2b37a0d5df7f0677525 Text-content-sha1: 094392cfddae63e113de72f342ff2df1c6472db3 Content-length: 26 One Two Three For Five Revision-number: 6 Prop-content-length: 117 Content-length: 117 K 7 svn:log V 17 merge second typo K 10 svn:author V 5 Michi K 8 svn:date V 27 2011-04-28T17:54:19.578125Z PROPS-END Node-path: branches/branch1/dir Node-kind: dir Node-action: change Prop-content-length: 47 Content-length: 47 K 13 svn:mergeinfo V 12 /trunk/dir:4 PROPS-END Node-path: branches/branch1/dir/file.txt Node-kind: file Node-action: change Text-content-length: 27 Text-content-md5: b7427b1a57551e6b5535a313214ebc1d Text-content-sha1: 42ab6c99f82597ca9cf326b33bad8326bb52e507 Content-length: 27 One Two Three Four Five
RE: repo on Windows -- why not?
> -Original Message- > From: Blair Zajac [mailto:bl...@orcaware.com] > Sent: donderdag 28 april 2011 19:39 > To: Danil Shopyrin > Cc: Michael Hüttermann; Bob Archer; users@subversion.apache.org > Subject: Re: repo on Windows -- why not? > > On 4/28/11 9:42 AM, Danil Shopyrin wrote: > >> are there any arguments to prefer Windows? (beside arguments that you > drive > >> a Windows shop) > >> ok, looks like I have to adjust the section a bit. > > > > It's also very important to integrate Subversion seamlessly with > > Active Directory and other existing Windows infrastructure (it applies > > to Windows shops, of course). > > Just to add a bit to this, if one has Active Directory but uses Unix servers, > one doesn't have to deploy on Windows to authenticate, can use LDAP in > httpd to > authenticate against AD. But currently this doesn't support NTLM/SSPI yet where you don't have to use/cache your credentials. Using mod_auth_sspi in Apache on Windows (or VisualSVN server, which does the same thing + adds their own extensions) does support that. Bert
RE: repo on Windows -- why not?
"Bert Huijben" wrote on 04/28/2011 01:18:09 PM: > > On 4/28/11 9:42 AM, Danil Shopyrin wrote: > > >> are there any arguments to prefer Windows? (beside arguments that you > > drive > > >> a Windows shop) > > >> ok, looks like I have to adjust the section a bit. > > > > > > It's also very important to integrate Subversion seamlessly with > > > Active Directory and other existing Windows infrastructure (it applies > > > to Windows shops, of course). > > > > Just to add a bit to this, if one has Active Directory but uses Unix > servers, > > one doesn't have to deploy on Windows to authenticate, can use LDAP in > > httpd to > > authenticate against AD. > > But currently this doesn't support NTLM/SSPI yet where you don't have to > use/cache your credentials. Using mod_auth_sspi in Apache on Windows (or > VisualSVN server, which does the same thing + adds their own extensions) > does support that. With some work(tm) mod_auth_kerb can support that on unix as well... Kevin R.
Re: swapping trunk and branch
I sometimes forget that I perceive time on a different scale to you mortals. On 28 April 2011 15:43, Nico Kadel-Garcia wrote: > On Wed, Apr 27, 2011 at 8:38 PM, Ben Carbery > wrote: > > Ok running 1.6 now and repository upgraded. Must have been a recent RH > > patch? > > Not recent: it was published with RHEL 5.6. >
just upgraded to svn 1.5 - confused
Someone said that merges are easy.. I have read the svn book about merges but it does not help. I create a branch and I can keep it synchronized with the trunk. I can even re-integrate the branch with the trunk. From now on, it seems the branch is useless since I can't continue working on it and re-sync with the trunk without getting absolutely nonsense conflicts.. :) What is the proper, if any, philosophy here? Shall one create a new branch each time it is re integrated with the trunk? Any hints helpful...! Thanks, Totte
Re: swapping trunk and branch
On Thu, Apr 28, 2011 at 7:44 PM, Ben Carbery wrote: > I sometimes forget that I perceive time on a different scale to you mortals. > > On 28 April 2011 15:43, Nico Kadel-Garcia wrote: >> >> On Wed, Apr 27, 2011 at 8:38 PM, Ben Carbery >> wrote: >> > Ok running 1.6 now and repository upgraded. Must have been a recent RH >> > patch? >> >> Not recent: it was published with RHEL 5.6. Heh. It was "not recent" enough for CentOS delayed release process to cost them a whole slew of users to Scientific Linux in response to 3 months of "when it's ready" messages from the project engineers. They've still not released CentOS 6.0. RHEL compatible developers are shifting distribution in droves. This is actually good for Subversion, at least this year. Sites reluctant to do wholesale updates in the name if "stability, such as going to 5.6 and getting Subversion 1.6, can simply update to RHEL 6 or Scientific Linux 6 and get the core of the update built-in.
Re: just upgraded to svn 1.5 - confused
On Thu, Apr 28, 2011 at 20:27, Totte Karlsson wrote: > Someone said that merges are easy.. I have read the svn book about merges > but it does not help. > > I create a branch and I can keep it synchronized with the trunk. > I can even re-integrate the branch with the trunk. > > From now on, it seems the branch is useless since I can't continue working > on it and re-sync with the trunk without getting absolutely nonsense > conflicts.. :) > > What is the proper, if any, philosophy here? Shall one create a new branch > each time it is re integrated with the trunk? If you want to keep the branch alive, don't use --reintegrate. >From the fine manual: "In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk" You will want to read http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice if you plan on using --reintegrate while keeping the branch around.
Re: just upgraded to svn 1.5 - confused
You will want to read http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice if you plan on using --reintegrate while keeping the branch around. Thanks! It will save me much time!
