Pre commit hook script help needed
Hello all, I have this issue with me. I have a SVN structure foo like this : Foo | | |_ Docs | | | |__ Bar Now there is a pre-commit hook that checks for some conditions before allowing commits into Foo. However, I want to exclude Docs folder/file from this checking exercise. I want this checking to be implemented only for Bar (and also for all the modules inside Bar, if there are any multiple modules inside Bar). How do I achieve this ? I am new to the whole SVN thing and also have no experience in scripting. Please help. Best regards, Amitakhya Phukan
Which version of subversion is the best?
Hi, I'm planning to upgrade existing subversion. we recently use subversion 1.4.5. I'm asking about versions of subversion. which one is the best? and why is it the best? Could you explain about this subject to determine to upgrade stable version? I need your help? thanks..
Subversion Exception in 1.7.1/2
I have just started to use the svn:externals keyword. I am checking out a svn folder to Windows desktop, but have set the svn:externals property on this folder to check out a lib at C:/lib: svn:externals C:/lib The lib is a svn repository containing only binary files and no folders. When I check out/update (the folder with the property set) and the lib is not present, everything gets checked out as expected but get the following error: External failed: C:\lib Error: In file Error: 'D:\Development\SVN\Releases\TortoiseSVN-1.7.2\ext\subversion\subversion\libsvn_wc\wc_db.c' Error: line 2890: assertion failed (svn_dirent_is_ancestor(wcroot->abspath, Error: local_abspath)) Regards PCoulson Paul Coulson Software Engineer Senscient Tel: 01202 606473 Mob: 07963 114556 pcoul...@senscient.com
Re: Which version of subversion is the best?
1.7.2 --- the release (.2) in the latest minor line (1.7.x) aykut kanyılmaz wrote on Mon, Dec 12, 2011 at 14:38:55 +0200: > Hi, > > I'm planning to upgrade existing subversion. we recently use subversion > 1.4.5. > > I'm asking about versions of subversion. > > which one is the best? and why is it the best? > > Could you explain about this subject to determine to upgrade stable version? > > I need your help? > > thanks..
Re: Subversion Exception in 1.7.1/2
Paul Coulson writes: > I am checking out a svn folder to Windows desktop, but have set the > svn:externals property on this folder to check out a lib at C:/lib: > > svn:externals C:/lib This is issue 4073: http://subversion.tigris.org/issues/show_bug.cgi?id=4073 use a relative path such as "lib" rather than "C:/lib". -- Philip
svn: E170001: Unable to connect to a repository at URL svn://
On one system running ~amd64 Gentoo Linux, all svn:// repository URLs return svn: E170001. I have tested repositories on multiple hosts e.g. Gentoo Overlay, Zope, etc. to rule out auth issues with a specific server. My other Gentoo ~amd64 systems work fine with svn:// urls. What dependency of subversion would be involved with svn:// URLs only, such that a problem with that dependency would not affect subversion's ability to interface with http(s):// urls? I have rebuilt subversion, cyrus-sasl and neon. Current versions are: dev-vcs/subversion-1.7.1 dev-libs/cyrus-sasl-2.1.25 net-libs/neon-0.29.6 Thanks, Jeff
Re: svn: E170001: Unable to connect to a repository at URL svn://
On Mon, Dec 12, 2011 at 07:28:59PM +, Jeff Kowalczyk wrote: > On one system running ~amd64 Gentoo Linux, all svn:// repository URLs return > svn: E170001. I have tested repositories on multiple hosts e.g. Gentoo > Overlay, > Zope, etc. to rule out auth issues with a specific server. My other Gentoo > ~amd64 systems work fine with svn:// urls. > > What dependency of subversion would be involved with svn:// URLs only, such > that > a problem with that dependency would not affect subversion's ability to > interface with http(s):// urls? > > I have rebuilt subversion, cyrus-sasl and neon. Current versions are: > > dev-vcs/subversion-1.7.1 > dev-libs/cyrus-sasl-2.1.25 > net-libs/neon-0.29.6 E170001 means SVN_ERR_RA_NOT_AUTHORIZED. This sounds some problem with your cyrus-sasl package. Reminds me of this: http://marc.info/?l=openbsd-ports&m=131805779110751&w=2
Re: svn: E170001: Unable to connect to a repository at URL svn://
Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 19:28:59 +: > What dependency of subversion would be involved with svn:// URLs only, such > that > a problem with that dependency would not affect subversion's ability to > interface with http(s):// urls? cyrus-sasl (which is an optional dependency, not a mandatory/required one)
Re: svn: E170001: Unable to connect to a repository at URL svn://
Stefan Sperling elego.de> writes: > > > > What dependency of subversion would be involved with svn:// URLs only, > > such that > > a problem with that dependency would not affect subversion's ability to > > interface with http(s):// urls? > > > > I have rebuilt subversion, cyrus-sasl and neon. Current versions are: > > > > dev-vcs/subversion-1.7.1 > > dev-libs/cyrus-sasl-2.1.25 > > net-libs/neon-0.29.6 > > E170001 means SVN_ERR_RA_NOT_AUTHORIZED. > This sounds some problem with your cyrus-sasl package. > Reminds me of this: http://marc.info/?l=openbsd-ports&m=131805779110751&w=2 Thanks for the suggestion. I just now rebuild cyrus-sasl and subversion in that order. No change in behavior. Jeff
Re: svn: E170001: Unable to connect to a repository at URL svn://
On Mon, Dec 12, 2011 at 07:53:42PM +, Jeff Kowalczyk wrote: > Stefan Sperling elego.de> writes: > > > > > > What dependency of subversion would be involved with svn:// URLs only, > > > such that > > > a problem with that dependency would not affect subversion's ability to > > > interface with http(s):// urls? > > > > > > I have rebuilt subversion, cyrus-sasl and neon. Current versions are: > > > > > > dev-vcs/subversion-1.7.1 > > > dev-libs/cyrus-sasl-2.1.25 > > > net-libs/neon-0.29.6 > > > > E170001 means SVN_ERR_RA_NOT_AUTHORIZED. > > This sounds some problem with your cyrus-sasl package. > > Reminds me of this: http://marc.info/?l=openbsd-ports&m=131805779110751&w=2 > > Thanks for the suggestion. I just now rebuild cyrus-sasl and subversion in > that > order. No change in behavior. Well, I don't know if the temporary error (missing .la files) that slipped into the OpenBSD package is also present in gentoo. Just recompiling things won't magically fix anything. You'll need to figure out if the gentoo sasl packages is broken or not. Do other applications that use sasl work fine?
Re: svn: E170001: Unable to connect to a repository at URL svn://
Stefan Sperling wrote on Mon, Dec 12, 2011 at 20:58:39 +0100: > On Mon, Dec 12, 2011 at 07:53:42PM +, Jeff Kowalczyk wrote: > > Stefan Sperling elego.de> writes: > > > > > > > > What dependency of subversion would be involved with svn:// URLs only, > > > > such that > > > > a problem with that dependency would not affect subversion's ability to > > > > interface with http(s):// urls? > > > > > > > > I have rebuilt subversion, cyrus-sasl and neon. Current versions are: > > > > > > > > dev-vcs/subversion-1.7.1 > > > > dev-libs/cyrus-sasl-2.1.25 > > > > net-libs/neon-0.29.6 > > > > > > E170001 means SVN_ERR_RA_NOT_AUTHORIZED. > > > This sounds some problem with your cyrus-sasl package. > > > Reminds me of this: > > > http://marc.info/?l=openbsd-ports&m=131805779110751&w=2 > > > > Thanks for the suggestion. I just now rebuild cyrus-sasl and subversion in > > that > > order. No change in behavior. > > Well, I don't know if the temporary error (missing .la files) that slipped > into the OpenBSD package is also present in gentoo. > > Just recompiling things won't magically fix anything. > You'll need to figure out if the gentoo sasl packages is broken or not. > Do other applications that use sasl work fine? Do you use sasl authentication? If not, try building svn without sasl.
RE: svn: E170001: Unable to connect to a repository at URL svn://
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: Monday, December 12, 2011 3:16 PM > To: Jeff Kowalczyk; users@subversion.apache.org > Subject: Re: svn: E170001: Unable to connect to a repository at URL > svn:// > > Stefan Sperling wrote on Mon, Dec 12, 2011 at 20:58:39 +0100: > > On Mon, Dec 12, 2011 at 07:53:42PM +, Jeff Kowalczyk wrote: > > > Stefan Sperling elego.de> writes: > > > > > > > > > > What dependency of subversion would be involved with svn:// > URLs only, > > > > > such that > > > > > a problem with that dependency would not affect subversion's > ability to > > > > > interface with http(s):// urls? > > > > > > > > > > I have rebuilt subversion, cyrus-sasl and neon. Current > versions are: > > > > > > > > > > dev-vcs/subversion-1.7.1 > > > > > dev-libs/cyrus-sasl-2.1.25 > > > > > net-libs/neon-0.29.6 > > > > > > > > E170001 means SVN_ERR_RA_NOT_AUTHORIZED. > > > > This sounds some problem with your cyrus-sasl package. > > > > Reminds me of this: http://marc.info/?l=openbsd- > ports&m=131805779110751&w=2 > > > > > > Thanks for the suggestion. I just now rebuild cyrus-sasl and > subversion in that > > > order. No change in behavior. > > > > Well, I don't know if the temporary error (missing .la files) that > slipped > > into the OpenBSD package is also present in gentoo. > > > > Just recompiling things won't magically fix anything. > > You'll need to figure out if the gentoo sasl packages is broken or > not. > > Do other applications that use sasl work fine? > > Do you use sasl authentication? If not, try building svn without sasl. Just thought I'd chime in here as I'm on Gentoo and working fine. Just did an emerge --sync and double checked my update status. subversion-1.6.17-r78 cyrus-sasl-2.1.23-r4 neon-0.29.6 Those are the latest stable packages on x86 and amd64. I'm compiled with the following use flags enabled: apache2 berkdb dso extras gnome-keyring sasl webdav-neon
Re: Pre commit hook script help needed
On Dec 12, 2011, at 05:19, Amitakhya Phukan wrote: > I have this issue with me. I have a SVN structure foo like this : > > Foo > | > | > |_ Docs > | > | > | > |__ Bar > > > Now there is a pre-commit hook that checks for some conditions before > allowing commits into Foo. However, I want to exclude Docs folder/file from > this checking exercise. I want this checking to be implemented only for Bar > (and also for all the modules inside Bar, if there are any multiple modules > inside Bar). How do I achieve this ? > > I am new to the whole SVN thing and also have no experience in scripting. If you're using something like bash to write your post-commit hook script, you'll be running "svnlook changed" to see what files were changed by the revision, and then for each one, you'll be doing your check. In between those steps (getting the list of files, and checking them), filter out the ones you don't want to check (those in Docs). For example using "grep -v /Docs/". Alternately, discard everything *except* the paths you want to check, e.g. Bar: "grep /Bar/".
Re: svn: E170001: Unable to connect to a repository at URL svn://
Brenden Walker drbsystems.com> writes: > Just thought I'd chime in here as I'm on Gentoo and working fine. > Just did an emerge --sync and double checked my update status. > > subversion-1.6.17-r78 > cyrus-sasl-2.1.23-r4 > neon-0.29.6 > > Those are the latest stable packages on x86 and amd64. > > I'm compiled with the following use flags enabled: > apache2 berkdb dso extras gnome-keyring sasl webdav-neon Thanks everyone for the help. Like Branden, I have four other Gentoo ~amd64 boxes with subversion use flag sasl, and they work fine. This laptop has always worked fine too, until about 2011-12-05. Gentoo currently removes .la files, IIUC, after the source compilation stage. I ran the deprecated tool to find and remove them, just in case. No .la files were found from any package. $ sudo lafilefixer --justfixit ... /usr/lib64/libsasl2.la already clean, skipping update. ... The subversion and cyrus-sasl packages are built with the following use flags. (-sasl configured just now) dev-libs/cyrus-sasl-2.1.25 USE="gdbm mysql pam postgres sqlite ssl -authdaemond -berkdb -java -kerberos -ldapdb -openldap -sample -srp -static-libs -urandom" dev-vcs/subversion-1.7.1 USE="apache2 bash-completion nls perl python webdav-neon -berkdb -ctypes-python -debug -doc -dso -extras -gnome-keyring -java -kde -ruby -sasl -vim-syntax -webdav-serf" I am now able to access svn:// urls, so the local problem is masked, although not fully understood. I'd like to follow it to the cause so I can file a Gentoo bug if needed. Are there any files under etc/ or ~/.subversion that might influence subversion's protocol to access to svn:// urls? I had previously cleared out ~/.subversion/auth FWIW. I'm grasping for something that might be different on this machine than the others. Thanks, Jeff
Re: svn: E170001: Unable to connect to a repository at URL svn://
Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 20:59:00 +: > I am now able to access svn:// urls, so the local problem is masked, although > not fully understood. I'd like to follow it to the cause so I can file a > Gentoo > bug if needed. > Can you eavesdrop the svn:// protocol handshake and see which authentication methods are being (a) offered by the server, (b) used? Protocol docs in in subversion/libsvn_ra_svn/protocol. > Are there any files under etc/ or ~/.subversion that might influence > subversion's protocol to access to svn:// urls? I had previously cleared out > ~/.subversion/auth FWIW. I'm grasping for something that might be different on > this machine than the others. > Does libsasl have any client-side config files? > Thanks, > Jeff >
Re: svn: E170001: Unable to connect to a repository at URL svn://
Daniel Shahaf daniel.shahaf.name> writes: > Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 20:59:00 +: > > I am now able to access svn:// urls, so the local problem is > > masked, although not fully understood. I'd like to follow it to > > the cause so I can file a Gentoo bug if needed. > > > > Can you eavesdrop the svn:// protocol handshake and see which > authentication methods are being (a) offered by the server, (b) > used? > > Protocol docs in in subversion/libsvn_ra_svn/protocol. > > > Are there any files under etc/ or ~/.subversion that might > > influence subversion's protocol to access to svn:// urls? I had > > previously cleared out ~/.subversion/auth FWIW. I'm grasping for > > something that might be different on this machine than the others. > > Does libsasl have any client-side config files? I will see if I can get wireshark to isolate that traffic. Re: config files, are those under /etc what you were asking about? $ sudo equery files cyrus-sasl |grep "/etc" /etc /etc/conf.d /etc/conf.d/saslauthd /etc/init.d /etc/init.d/pwcheck /etc/init.d/saslauthd /etc/pam.d /etc/pam.d/saslauthd /etc/sasl2 /etc/sasl2/.keep_dev-libs_cyrus-sasl-2 Thanks, Jeff
Re: Hypervisor Support - Virtual Guest Image Versioning
On Sun, Dec 11, 2011 at 7:50 PM, wrote: > I am specifically looking at the Xen hypervisor but it may have broader > applicability. > > I am in a personal workstation environment using Xen as a hypervisor > managing a half dozen guest operating systems. I am planning on one of > those to be an Apache/SVN server. There will be a variety of > repositories. I am considering how I may implement a repository to > track the versioning of guest images. I would like to keep version > histories of the different guests; experimental perturbations, upgrades, > etc. I like the SVN version graph and I am wondering about how much I > can add notes to clarify the differences. Additionally, update the > notes when in retrospect, more information is needed for historical > entries. > > Since the binaries are large, I will probably need to extend the storage > to a slower, cheaper media for the older versions. I want to keep fast > response for new entries. I am wondering how I might have the best of > both worlds and still be able to pull up a full historical graph. Do *NOT* attempt to store image binaries. Seriuosly. You're asking for pain, since each image will be profoundly distinct from all the others. If you have to do something like this, arrange to use a backup sytem that backups the *filesystems* to a secondary storage device, and you can compare contents from that. If you feel the need, you can add some wrappers to grab boot loaders and partition indices. But storing the entire disk image is like putting the apple tree in your refrigerator to make sure the apples stay fresh: it's an amazing expenditure in resources. > I plan to use SVN both locally and over the Internet for personal use > only; I am looking for comments/cogestions on setting up for this > service. > > I would really like to hear comments and suggestions on implementing > Apache/SVN on such a hosted service and any about overall system > configuration. I profoundly dislike the Apache/SVN setup, and have said so before. This is partly because it's another layer of access control complexity that is orthogonal to the pre-commit or other built-in access configuration. The other, and more powerful reason, is that Linux and UNIX clients for Subversion store the passwords, by default, as plain-text in a well-known location in your home directory. It's possible to set up more clever password storage schemes, such as Gnome or KDE "wallets", but they remain awkward and difficult to use for unattended behavior such as nightly auto-build systems. So wherever feasible, I use svn+ssh. I've also seen reports that Kerberized access can work well, but that would require even more work to set up and could make a working setup even more difficult to access than users will tolerate.
Disk space problem
I am not too familiar with SVN, but have to use it now, on a Windows 2003 server. I have created a repository in the disk E, and start to import a large project to it. In the halfway, I got a message from the OS saying the C drive space is low, it seems to me that SVN is storing data onto the disk C. My questions are: 1. How should I stop the "import" process, without causing any problem, such as leave rubbish data in the disk? 2. How can I force SVN store data onto drive E (or any disk I specified) rather than on the C drive? Thanks in advance Xiaogang
Re: Disk space problem
Am 12.12.2011 23:40, schrieb Xiaogang Zhang: I am not too familiar with SVN, but have to use it now, on a Windows 2003 server. I have created a repository in the disk E, and start to import a large project to it. In the halfway, I got a message from the OS saying the C drive space is low, it seems to me that SVN is storing data onto the disk C. I guess it stores temporary data there. My questions are: 1. How should I stop the "import" process, without causing any problem, such as leave rubbish data in the disk? If you literally mean "svn import" with import process, then you don't have to do anything, because the import is done in one atomic transaction. If you mean something like "svnadmin load", this is not the case, there revisions are committed one by one. In that case, you should be able to resume the load operation from the first revision not loaded. 2. How can I force SVN store data onto drive E (or any disk I specified) rather than on the C drive? I think you can use %TMP% or %TEMP% to change this location. In any case, you specify the repository to load/import into, but SVN uses "normal" OS scrap space to first assemble the according new revision, but it should also clean up after itself. In no case is data stored there permanently. Greetings! Uli ** 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. **
