Re: Two-Site Subversion Repository Setup Ideas
Just my two cents... How secure is "secure"? Is it to stop a source code leak like Half-Life 2, where millions of dollars in intellectual property is paraded on the Internet and they are publicly humiliated? Or are they designing software for guided missiles? I think they're going to have to communicate more often than once a week. Set up a trusted staff member to act as courier, who drives back and forth every day. If you're really paranoid, ensure that the CD is encrypted by a method unknown to the courier, by a second staff member who is that staff member least friendly with the courier. Richard - Original Message - From: Nico Kadel-Garcia Sent: 06/06/11 01:58 PM To: Les Mikesell Subject: Re: Two-Site Subversion Repository Setup Ideas On Sun, Jun 5, 2011 at 10:19 PM, Les Mikesell wrote: > If it doesn't take too long for a round-trip, you could ship the working > copy from site B to site A, do the commit and update, and ship it back > before doing any more work at site B. Les, I'm looking right at his original post. > We have two sites wanting to use Subversion that are performing parallel development of the same software. Due to security restrictions, the two sites are unable to communicate electronically; all data transfers must be via media (CD-ROM/DVD). Site A is the main site and is responsible for overall configuration control. If they're security sensitive, sending the working copies back and forth becomes a security nightmare. It also becomes a major performance bottleneck for the remote site, who may really not appreciate being treated as second class citizens.
AW: Two-Site Subversion Repository Setup Ideas
Hi, Richard, Von: Richard Cavell [mailto:richardcav...@mail.com] > I think they're going to have to communicate more often than once a week. > Set up a trusted staff member to act as courier, who drives back and forth > every day. If you're really paranoid, ensure that the CD is encrypted by a > method unknown to the courier, by a second staff member who is that staff > member least friendly with the courier. Why the staff member least friendly with the courier? This raises the probability that they both can be bribed by an external independently, each of them relying on the other one, and they won't talk about that. Regards, Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Entwicklung Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys Internet-Forum: http://forum.3s-software.com Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915
Re: AW: Two-Site Subversion Repository Setup Ideas
My suggestion ensures that both staff will need to be corrupt in order for the source to leak. Here, there's an armoured car company that does large cash transfers, where every operation requires at least two staff to be present. They say that it's so that if someone attacks one staff member, there's another to back him up, but the real reason is so the staff can watch each other. I can think of many situations where such paranoia is necessary - like I said, even the leakage of Half-Life 2 is a multi-million dollar disaster that any company would gladly pay big money to avoid. I think that your problem is of the type that requires expertise in espionage/data security, more than in subversion itself. No technical solution is going to be able to overcome the problem of infrequent synchronization. Of course, you can do things like grouping certain files as being the domain of site A, and the rest to be the domain of site B, or you could communicate every day by phone to describe the changes without actually publishing them to each other. But I think really, you have to sync more frequently. Richard - Original Message - From: Markus Schaber Sent: 06/06/11 06:20 PM To: Richard Cavell, Nico Kadel-Garcia Subject: AW: Two-Site Subversion Repository Setup Ideas Hi, Richard, Von: Richard Cavell [mailto:richardcav...@mail.com] > I think they're going to have to communicate more often than once a week. Set up a trusted staff member to act as courier, who drives back and forth every day. If you're really paranoid, ensure that the CD is encrypted by a method unknown to the courier, by a second staff member who is that staff member least friendly with the courier. Why the staff member least friendly with the courier? This raises the probability that they both can be bribed by an external independently, each of them relying on the other one, and they won't talk about that. Regards, Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Entwicklung Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys Internet-Forum: http://forum.3s-software.com Geschäftsführer: Dipl.Inf. Diet er Hess, Dipl.Inf. Manfred Werner | Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915
RE: Two-Site Subversion Repository Setup Ideas
> I am looking for suggestions from the community as to how > best address the setup issue outlined below. > > We have two sites wanting to use Subversion that are > performing parallel development of the same software. Due to > security restrictions, the two sites are unable to > communicate electronically; all data transfers must be via > media (CD-ROM/DVD). Site A is the main site and is > responsible for overall configuration control. > > Is there a way to setup the two subversion repositories to > somehow automate keeping the two repositories in sync? We > are usually passing media back and forth once a week, but > currently we are doing a manual sync process that is both > time-consuming and error-prone. People here will hate me for this, but I think you should switch to a DVCS (Distributed Version Control System), like Mercurial or git. While I don't know git, in Mercurial you have the possibility to save and export you changes as so-called bundle at one site and import them at the other site. For more information: http://www.selenic.com/mercurial/hg.1.html#bundle Best regards Andreas -- Andreas Tscharner -- "Intruder on level one. All Aliens please proceed to level one." -- Call in "Alien: Resurrection" CT-Dienstleistungen neu bei Wenzel Metromec = Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell? Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren? Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen! Testen Sie uns und unsere neue WENZEL exaCT Anlage. Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf. mailto:c...@metromec.ch?subject=CT-Dienstleistungen
Re: Two-Site Subversion Repository Setup Ideas
On Mon, Jun 06, 2011 at 11:55:42AM +0200, Andreas Tscharner wrote: > People here will hate me for this, but I think you should switch to a > DVCS (Distributed Version Control System), like Mercurial or git. If people hate you for making this suggestion then that's their fault. Not every tool is made for every imaginable job. The use case described is a good fit for distributed tools because it is part of the problem domain they have been designed for. Subversion has been designed for different use cases. There are use cases where Subversion is more suitable than git or hg, but that is not going to help with this particular use case. Unfortunately, we cannot use any of these tools to take a bath. We must accept that because the tools haven't been designed to be bathtubs but version control systems. Too bad!
Re: Two-Site Subversion Repository Setup Ideas
On Sun, 05 Jun 2011 20:52:38 +, Nico Kadel-Garcia wrote: ... > If they can't communicate electronically, you'll have to synchronize > by physical media. Subversion is built on top of CVS paradighms, with > a central repository. Parall, disconnected development *cannot work* > with that model, not without someone manually resolving all the > inevitable discrepancies and merge issues in parallel code lines. > > This is a case where you need to lay out what your limitations on > connectivity really are: no connections? No patches transmitted? No > auto-propagation? Nothing? Then they're two independent projects, with > entire source trees. That is not necessarily the case. I remember times when I just took the tree of the customer, hacked at it in the company, and when I came back, we took the original tree, the current customer tree and my modified tree, and applied diff3 to it, getting all the necessary merges. (The hard part is, of course, handling new and deleted files, but that wasn't that much of an issue back then.) Of course, I you do sync only once a week that precludes someone from the other site agily adding some library feature to be used immediately. Unless you get him physically to the other site, that is. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Two-Site Subversion Repository Setup Ideas
On Sun, 05 Jun 2011 14:57:22 +, Randolph, Christian [USA] wrote: ... > Is there a way to setup the two subversion repositories to somehow automate > keeping the two repositories in sync? No (AFAIF, as usual), not out of the box. > We are usually passing media back and forth once a week, but currently we are > doing a manual sync process that is both time-consuming and error-prone. I don't think that there is a way of synchronizing all branches of two svn repositories when different commit are made to each of them. It would be relatively easy to keep a single branch (say, trunk) synchronized with its brother on the other side, by carrying the tree back and forth, and doing some script magic. You need to remember the last revision you transported, though. (You will also lose renames, and svn:externals will be interesting.) The 'vendor model' won't work because it does not work with cyclic imports; it does not give the merge infos that are needed in this case. > Any suggestions would be greatly appreciated. The 'dirtiest' model of synchronization is to use git&svn in the same sandbox, with proper .ignores, and use the git repos for transfer. But that by itself is also somewhat error-prone. I use that on svn projects when I need to work on multiple machines, but it's not an industrial method. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
RE: Two-Site Subversion Repository Setup Ideas
Am Montag, den 06.06.2011, 11:55 +0200 schrieb Andreas Tscharner: > > I am looking for suggestions from the community as to how > > best address the setup issue outlined below. > > > > We have two sites wanting to use Subversion that are > > performing parallel development of the same software. Due to > > security restrictions, the two sites are unable to > > communicate electronically; all data transfers must be via > > media (CD-ROM/DVD). Site A is the main site and is > > responsible for overall configuration control. > > > > Is there a way to setup the two subversion repositories to > > somehow automate keeping the two repositories in sync? We > > are usually passing media back and forth once a week, but > > currently we are doing a manual sync process that is both > > time-consuming and error-prone. > > People here will hate me for this, but I think you should switch to a > DVCS (Distributed Version Control System), like Mercurial or git. While > I don't know git, in Mercurial you have the possibility to save and > export you changes as so-called bundle at one site and import them at > the other site. For more information: > http://www.selenic.com/mercurial/hg.1.html#bundle Monotone has similar capabilities, too. And there's ClearCase(tm) with MultiSite(tm), of course (if your management is willing to spend some $$$). HTH... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Two-Site Subversion Repository Setup Ideas
On 6/6/11 7:33 AM, Heinrichs, Dirk wrote: Am Montag, den 06.06.2011, 11:55 +0200 schrieb Andreas Tscharner: I am looking for suggestions from the community as to how best address the setup issue outlined below. We have two sites wanting to use Subversion that are performing parallel development of the same software. Due to security restrictions, the two sites are unable to communicate electronically; all data transfers must be via media (CD-ROM/DVD). Site A is the main site and is responsible for overall configuration control. Is there a way to setup the two subversion repositories to somehow automate keeping the two repositories in sync? We are usually passing media back and forth once a week, but currently we are doing a manual sync process that is both time-consuming and error-prone. People here will hate me for this, but I think you should switch to a DVCS (Distributed Version Control System), like Mercurial or git. While I don't know git, in Mercurial you have the possibility to save and export you changes as so-called bundle at one site and import them at the other site. For more information: http://www.selenic.com/mercurial/hg.1.html#bundle Monotone has similar capabilities, too. And there's ClearCase(tm) with MultiSite(tm), of course (if your management is willing to spend some $$$). If you are doing this in 2 directions, won't the disconnected repositories eventually drift out of sync as the people resolving conflicts make different choices - regardless of how well the VCS manages the details? -- Les Mikesell lesmikes...@gmail.com
Re: Two-Site Subversion Repository Setup Ideas
On 6/5/11 10:58 PM, Nico Kadel-Garcia wrote: On Sun, Jun 5, 2011 at 10:19 PM, Les Mikesell wrote: If it doesn't take too long for a round-trip, you could ship the working copy from site B to site A, do the commit and update, and ship it back before doing any more work at site B. Les, I'm looking right at his original post. We have two sites wanting to use Subversion that are performing parallel development of the same software. Due to security restrictions, the two sites are unable to communicate electronically; all data transfers must be via media (CD-ROM/DVD). Site A is the main site and is responsible for overall configuration control. If they're security sensitive, sending the working copies back and forth becomes a security nightmare. It also becomes a major performance bottleneck for the remote site, who may really not appreciate being treated as second class citizens. Ummm, doesn't not having network access make you second class by definition? My point is that bits are pretty lightweight and transporting working copies would actually work as opposed to trying to keep 2 repos in sync, which won't. You could, of course keep copies of the working copy at both places and send diffs back and forth which would make it harder to steal the intermediate transfers and easier to fit on a dvd, but external 2.5" drive are nicely portable, go up to 1.5TB, and can be encrypted. But, the real problem is that besides doing the commit, site B's working copies have to be updated with the changes sent back and patched into place before they do any more work - and someone at site A has to resolve conflicts which may leave some surprising changes in the code coming back. The timing of that round trip might make it impractical. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion 1.6.17 Released
Around about 03/06/11 23:20, Nico Kadel-Garcia typed ... Faster than than it was for .6.16 or earlier with the Linux client? Good Yes, tested the new TSVN this morning on our standard codebase. A full checkout last week on the old TSVN took just shy of 15 mins. (2-3 of its dirs. have a few hundred files in, above the average) and this morning it was a little over 9 mins. Not to be sniffed at! I'm re-running our ~5,500 files-in-a-directory checkout now (was ~80 mins., dropping to ~8 IIRC with the patched and then 1.6.17 Linux command line). Mind you, it was only a minute to a local Linux ext3 in both cases :-) Yep, TSVN sorted; the old 80 min. run just took under 11 minutes (bit longer than my original patch-test runs as IT have stuffed our McAfee install and it gets in the way of everything now :-( ) -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Re: Two-Site Subversion Repository Setup Ideas
Am Montag, den 06.06.2011, 07:52 -0500 schrieb Les Mikesell: > If you are doing this in 2 directions, won't the disconnected > repositories eventually drift out of sync as the people resolving > conflicts make different choices - regardless of how well the VCS > manages the details? I guess you're talking about conflicts in the code? This can be handled by working on branches. If each task is done in its own branch, on which only one person should work, then conflict resolution is only needed when the branch is rebased to the latest tag (which is usually done by the person responsible for the branch). Merging the branch back to trunk (--reintegrate) is then conflict-free. Bye... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
svn+ sasl2 on MAC OS X 10.6 not authenitificatime us
Dear Subversion experts, I am tto establish SVN server with Cyrus SASL authentification but failed to properly set this. When using SVN repository with config/passwd authentification then it works perfectlyworks. But I am to do more secure authentification. I am sending you all SASL+SVN related settings I was to find ouit in P.S. part of this e-mail. I would like to ask you for any recomandation what I am doing wrong, please? Thank you for any answer I look forward hearing from you Yours faithfully Peter Fodrek P.S. /Users/mini1/my-bin/bin/svnserve --version svnserve, version 1.6.17 (r1128011) compiled Jun 6 2011, 14:53:15 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.apache.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository back-end (FS) modules are available: * fs_fs : Module for working with a plain file (FSFS) repository. Cyrus SASL authentication is available. dhcp28-108:~ mini1$ more /Users/mini1/my-bin/lib/sasl2/subversion.conf pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /Users/mini1/my-bin/druha saslauthd_path: /Users/mini1/my-bin/sbin mech_list: DIGEST-MD5 dhcp28-108:~ mini1$ ls -la /Users/mini1/my-bin/sbin/sasl* -rwxr-xr-x 1 mini1 staff 77176 Jun 6 14:40 /Users/mini1/my- bin/sbin/saslauthd -rwxr-xr-x 1 mini1 staff 251360 Jun 6 14:40 /Users/mini1/my- bin/sbin/sasldblistusers2 -rwxr-xr-x 1 mini1 staff 256120 Jun 6 14:40 /Users/mini1/my- bin/sbin/saslpasswd2 dhcp28-108:~ mini1$ /Users/mini1/my-bin/sbin/sasldblistusers2 /Users/mini1/my-bin/druha agentura@APVV: userPassword moj@Subversion: userPassword peter@APVV: cmusaslsecretOTP pokusny@APVV: userPassword test@APVV: cmusaslsecretOTP testovic@APVV: userPassword uni@Subversion: userPassword agentura@APVV: cmusaslsecretOTP moj@Subversion: cmusaslsecretOTP peter@APVV: userPassword pokusny@APVV: cmusaslsecretOTP test@APVV: userPassword testovic@APVV: cmusaslsecretOTP uni@Subversion: cmusaslsecretOTP dhcp28-108:~ mini1$ sudo killall -9 svnserve dhcp28-108:~ mini1$ sudo /Users/mini1/my-bin/bin/svnserve -d -r /opt/repos/ dhcp28-108:~ mini1$ cat /opt/repos/Plazma/conf/svnserve.conf ### This file controls the configuration of the svnserve daemon, if you ### use it to allow access to this repository. (If you only allow ### access through http: and/or file: URLs, then this file is ### irrelevant.) ### Visit http://subversion.tigris.org/ for more information. [general] ### These options control access to the repository for unauthenticated ### and authenticated users. Valid values are "write", "read", ### and "none". The sample settings below are the defaults. anon-access = none auth-access = write ### The password-db option controls the location of the password ### database file. Unless you specify a path starting with a /, ### the file's location is relative to the directory containing ### this configuration file. ### If SASL is enabled (see below), this file will NOT be used. ### Uncomment the line below to use the default password file. password-db = passwd ### The authz-db option controls the location of the authorization ### rules for path-based access control. Unless you specify a path ### starting with a /, the file's location is relative to the the ### directory containing this file. If you don't specify an ### authz-db, no path-based access control is done. ### Uncomment the line below to use the default authorization file. #authz-db = authz ### This option specifies the authentication realm of the repository. ### If two repositories have the same authentication realm, they should ### have the same password database, and vice versa. The default realm ### is repository's uuid. realm = APVV [sasl] ### This option specifies whether you want to use the Cyrus SASL ### library for authentication. Default is false. ### This section will be ignored if svnserve is not built with Cyrus ### SASL support; to check, run 'svnserve --version' and look for a line ### reading 'Cyrus SASL authentication is available.' use-sasl = true ### These options specify the desired strength of the security layer ### that you want SASL to provide. 0 means no encryption, 1 means ### integrity-checking only, values larger than 1 are correlated ### to the effective key length for encryption (e.g. 128 means 128-bit ### encryption). The values below are the defaults. #min-encryption = 0 #max-encryption = 256 pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /Users/mini1/my-bin/druha mech_list: DIGEST-MD5 dhcp28-108:~ mini1$ls -la /Users/mini1/my-bin/lib/sasl2/ total 1952 drwxr-xr-x 22 mini1 staff 748 Jun 6 15:52 . drwxr-xr-x 78 mini1 staff2652 Jun 6 14:59 .. -rw-r--r-- 1 mini1 staff 73640 Jun 6 14:39 libanonymous.a -rwxr-xr-x 1 mini1 staff 645 Jun 6 14:39 libanonymous.la -rw-r--r-- 1 mini1 staff 81880 Jun 6 14:39 libcrammd5.a -rwxr-xr-x 1 mini1 staff 639
Re: svnshell-like client
It's an interesting question... You're too use to RCS. CVS, for example, uses RCS format for files, but the files are on a remote server where no one but the CVS admin has access. I guess ClearCase via dynamic views comes closest to what you want. (You setup a "view", but can use the magical "@@" to see the branching and history structure. Using "@@" allows you to use standard Unix tools like "find" to do what you want). However, ClearCase is a massive, CPU hungry, and slow system. Many a Subversion site was a former ClearCase client. What you're asking for doesn't sound all that difficult. I can imagine a simple shell script that allows you to specify the URL when you invoke it, but provides you with a "svn> " prompt that allows you to use various commands. In fact, if this is something that others might be interested in, I might come up with something, maybe in Perl or even Python (it's about time I learn it). The basic script would provide a few very generic commands, but allow you to expand it in some sort of "plugin" architecture. For example, the basic script will have the "ls", "cat", and "cd" commands, but others could add a "find", "log", and other commands. On Tue, May 31, 2011 at 1:50 PM, Rick Varney wrote: > Hello, > > We are migrating from a RCS-like revision control system, RCE, to > Subversion. > > The users are accustomed to poking around in the directories where > the archive files are stored to see what's there in a Linux bash shell. > While it is possible to do this using the svn client commands by providing > the full path to objects in the repository, it is somewhat inconvenient. A > shell user accustomed to using cd, ls, and path completion to inspect a file > tree can't use the same methods when inspecting the repository. > > I noticed svnshell.py. This is similar to what I am looking for. However, > svnshell.py is a server-side script. I am looking for a client-side script > - we have users at multiple sites that will want to inspect the repository. > > The key features/commands I am looking for are: > > 1. a client-side script > 2. cd to change the current directory > 3. ls to list files > 4. path completion using the TAB key > 5. info command to invoke svn info on a repository file or dir > 6. log command to invoke svn log on a repository file or dir > 7. a simple find command > > Is there anything out there like this? I have not found anything in my web > searches so far. If not, any suggestions on what to use as a good starting > point? > > Best regards, > > Rick Varney -- David Weintraub qazw...@gmail.com
Do I need to use same APR between apache and subversion?
Hello, I am currently running subverison 1.6.11 with apache 2.2.15 I need to go to subversion 1.6.17. So I was just going to build subversion1.6.17 svn modules and put them into the apache2 modules directory. I tried to build subversion 1.6.17 with the apr libs from apache 2.2.15 but got an error trying to build subversion. I am thinking I need to install fresh standalone apr's and then build subversion using the new standalone aprs. Will this work, or do I need to use the same apr's between apache and subversion? thanks, Sam
Re: Do I need to use same APR between apache and subversion?
On Jun 6, 2011, at 15:04, Sam Theman wrote: > I am currently running subverison 1.6.11 with apache 2.2.15 > > I need to go to subversion 1.6.17. So I was just going to build > subversion1.6.17 svn modules and put them into the apache2 modules directory. > > I tried to build subversion 1.6.17 with the apr libs from apache 2.2.15 but > got an error trying to build subversion. I am thinking I need to install > fresh standalone apr's and then build subversion using the new standalone > aprs. Will this work, or do I need to use the same apr's between apache and > subversion? Yes, you should build Apache and Subversion against the same versions of APR and APR-util. I would have thought that the versions of APR and APR-util provided with Apache should have been sufficient, then again I didn't realize Apache was being provided with any version of APR or APR-util. What error did you get? Can you upgrade APR, APR-util and Apache to the latest versions? Latest version of Apache is 2.2.19, APR is 1.4.5, APR-util is 1.3.12.
