RE: finding out the repository version
The easiest way to verify is to run svn upgrade again. If it succeeds without an error it is at the last version. If you want to look further you can check the format file in the root of the repository and with fsfs in its db subdirectory. For my just created 1.6 repository I see version 5 as first line of the format file in the root of the db and version 4 (and some sharding config options) in the format file of the subdirectory. Bert From: Kriparam Faraday [mailto:kripa...@gmail.com] Sent: vrijdag 27 augustus 2010 0:06 To: users@subversion.apache.org Subject: finding out the repository version I have upgraded a repository from 1.4 version to 1.6 version by running the "svnadmin upgrade" command. is there anyway to verify it? in other words, I just want to know if there is a way to find out the version of the repository. Thanks in advance.
RE: Deleteing svn:mergeinfo after reintegration
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: 26 August 2010 17:47 > To: Giulio Troccoli; users@subversion.apache.org > Subject: RE: Deleteing svn:mergeinfo after reintegration > > > I have a repostiory with the following svn:mergeinfo > property on trunk > > > > /branches/DR:353-683 > > /branches/xplorer:589-623 > > > > Both DR and xplorer branches have been reintegrated and now > deleted. > > Can I delete the mergeinfo then? > > > > The reason I'm asking is because now, when I merge trunk into other > > branches I have got these mergeinfo too, which I'm not > interested in > > the least, and more than once they confused me. > > > > Giulio Troccoli > > I would say, it depends. Do you have any branches that were > copied from those branches that you might merge into trunk? > > BOb No Bob, all my branches are copied from trunk.
Re: Unable to view repository list
On Fri, Aug 27, 2010 at 7:13 AM, Neson Maxmelbin (RBEI/EMT5) wrote: > > Hello Guys, > > I have setup SVN 1.6 with Apache 2.9 on Windows Server 2003 SP2 with LDAP > conf. > > I can access the repositories ok, but unable to view the parent path on web > so that I can see the list of repositories. > In my httpd.conf , the last section reads as follows .. > Request your help. > Thanks > > Location /repos> > > DAV svn > SVNParentPath D:/svnrepo > > SVNListParentPath On > > SVNIndexXSLT "/svnindex.xsl" > > SVNAutoversioning on > > # how to authenticate a user > AuthType Basic > > AuthName "Subversion Repository for *" > AuthBasicProvider ldap > > > > AuthzLDAPAuthoritative on > > AuthLDAPBindDN "CN=*,OU=,OU=***,OU=,DC=**,DC=,DC=com" > AuthLDAPBindPassword "***" > AuthLDAPURL > "ldap://***:32**/DC=,DC=?sAMAccountName?sub?(objectClass=*)" > > Require valid-user > > AuthzSVNAccessFile D:/svnrepo/config/ldap-access-file.txt > > # SSPI settings > # SSPIAuth On > # SSPIOmitDomain On > # SSPIAuthoritative On > # SSPIDomain > # SSPIOfferBasic On > > # try anonymous access first, resort to real > # authentication if necessary. > # Satisfy Any > > > > I have also added the following after LoadModule lines … > > # Work around authz and SVNListParentPath issue > RedirectMatch ^(/repos)$ $1/ > > In the access configuration file , I have added the following line also > > [:/] > * = rw I think you need a trailing slash in the Location directive: This is actually related to a bug (for which you need to use the RedirectMatch workaround etc.), which seems to be fixed for the upcoming 1.7 release: http://subversion.tigris.org/issues/show_bug.cgi?id=2753 - SVNListParentPath feature doesn't work when svn authz is used. HTH, -- Johan
Re: Ubuntu: store user credentials for svn-client
On 08/24/10 14:30, bebop52 wrote: > I checked out a Latex-Project from Google-Code Projecthosting, using > subversion, for which I installed a client on my Ubuntu Lucid > machine. Now I want to work to use emacs to edit the projectfiles and > to commit the changes to the Google-Code repository. > > After hitting C-x v v I recieve the following error message: > " Could not authenticate to server: rejected Basic challenge > (https://xxx.googlecode.com)" > > After a lot of research I still don't understand where and how to > store my usercredentials (username and password) so that the > svn-client can successfully authenticate to the googlecode > repository. I know it is a very basic question, but please explain it > in simple words cause I'm really stuck. > > I discovered the .subversion directory in my home directory. All the > files in the auth subdirectory are empty. I frankly do not understand > how to edit the config and servers files to make it work with > googlecode. > > Thanks for any help. > I can't help but can sympathize. I found a very similar problem after upgrading ubuntu 8.04 -> ubuntu 10.04. However, my symptoms were slightly different. I got the: Could not authenticate message but before that I got some query containing "gnome keyring". Here's the actual session: [CODE] ~/prog_dev/boost-svn/ro/sandbox/rw/variadic_templates $ svn commit -m "add macro, ARG_CONSTANCY, to test driver" Password for '(null)' GNOME keyring: svn: Commit failed (details follow): svn: MKACTIVITY of '/svn/boost/!svn/act/018d0a5a-eee7-49b3-b42e-b5295ef7b8f8': authorization failed: Could not authenticate to server: rejected Basic challenge (https://svn.boost.org) ~/prog_dev/boost-svn/ro/sandbox/rw/variadic_templates $ [/CODE] So, I'd like to echo bebop52's plea for help. -Larry
Re: SSL handshake failed: SSL error: A TLS warning alert has been received.
On 08/11/10 13:46, Lieven Govaerts wrote: > On Wed, Aug 11, 2010 at 8:28 PM, Gero wrote: >> On Wed, 2010-08-11, Lieven Govaerts wrote: >> On Wed, Aug 11, Gero wrote: Hi, After moving to a new system (Kubuntu Hardy -> Lucid) I can no longer access an SVN repository: $ svn update svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://example.com) I assume the old svn client version was 1.4.6: http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6. The repository has other users for whom it continues to work. Any ideas what is going on? >>> >>> Can you still access that folder with a web browser, without a >>> certificate warning? >>> I think 1.6.6 is more strict on validating server certificates as >>> 1.4.6, not sure though. >> >> Yes, web access still works with no warnings. >> > > Well, that error message isn't telling a lot. Might be interesting to > find out what's logged in the server's error log. > > Lieven > This is the 2nd thread that's mentioned ubuntu's lucid. The last post to the other thread is found here: http://article.gmane.org/gmane.comp.version-control.subversion.user/99801 Maybe ubuntu people have some idea what's wrong; however, I've already posted a question here: http://ubuntuforums.org/showthread.php?t=1561623 but have gotten no reply :(
add * ignores new files in subdirectories.
Subversion Dev team: Thanks for all your hard work. I just began using subversion and it is great. Among other things, it is fast. One complaint. I'm using a Linux system, fyi. As a new user it was my expectation that 'svn add *' called from within the root of my version-controlled root directory would result in *all* changes that had been made within the file system to be scheduled for inclusion on the next commit. Instead, it ignored a whole raft of new files that were buried in subdirectories. It took me a while of poking around to find this out. The behavior I expected was that "svn add *" would schedule a snapshot of the entire directory tree. Of course, to actually make this happen, I had to use the "svn add * --force" option. It's also worth noting that the option "svn add * --depth infinity" also did not add the files that were buried in the subdirectores; they were not added to be included on the next commit. Why would you have subversion skip a bunch of files? That makes no sense. The "import" command conversely, adds all the files in all the subdirectories, when a new directory is first brought under version control. It seems to me, the default behavior should be the obvious behavior. Or maybe there is more that I don't yet understand. If so, I would like to hear. Thanks. It is great software. David Heitzman -- Life moves on, whether we act as cowards, or heroes.
Re: add * ignores new files in subdirectories.
David, On Fri, Aug 27, 2010 at 3:59 PM, David H wrote: > > As a new user it was my expectation that 'svn add *' called from within the > root > of my version-controlled root directory would result in *all* changes that > had been > made within the file system to be scheduled for inclusion on the next commit. > > Instead, it ignored a whole raft of new files that were buried in > subdirectories. > > It took me a while of poking around to find this out. > > The behavior I expected was that "svn add *" would schedule a snapshot of the > entire directory tree. Of course, to actually make this happen, I had to use > the "svn add * --force" > option. It's also worth noting that the option "svn add * --depth infinity" > also did not add the files that were > buried in the subdirectores; they were not added to be included on the next > commit. > > Why would you have subversion skip a bunch of files? That makes no sense. > Its likely that you are seeing the result of the default global-ignores config value, described here: http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html --- global-ignores When running the svn status command, Subversion lists unversioned files and directories along with the versioned ones, annotating them with a ? character (see the section called “See an overview of your changes”). Sometimes it can be annoying to see uninteresting, unversioned items—for example, object files that result from a program's compilation—in this display. The global-ignoresoption is a list of whitespace-delimited globs that describe the names of files and directories that Subversion should not display unless they are versioned. The default value is *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store . As well as svn status, the svn add and svn import commands also ignore files that match the list when they are scanning a directory. You can override this behavior for a single instance of any of these commands by explicitly specifying the filename, or by using the --no-ignore command-line flag. chris
Re: add * ignores new files in subdirectories.
Hi David, the cause is your shell expanding the * to the list of all files in the directory before invoking the command. So in a directory containing the files foo, bar and baz.txt, the command "svn add *" actually translates to "svn add foo bar baz.txt" before the command is executed. Svn never even sees the star. You'll see a similar behaviour with ignored files being added when using "svn add *". The proper command is "svn add --force ." which adds all new files under the current directory while still taking ignores into account. Felix Von meinem iPhone gesendet Am 27.08.2010 um 21:59 schrieb David H : > Subversion Dev team: > > Thanks for all your hard work. I just began using subversion and it is great. > > Among other things, it is fast. > > One complaint. > > I'm using a Linux system, fyi. > > As a new user it was my expectation that 'svn add *' called from within the > root > of my version-controlled root directory would result in *all* changes that > had been > made within the file system to be scheduled for inclusion on the next commit. > > Instead, it ignored a whole raft of new files that were buried in > subdirectories. > > It took me a while of poking around to find this out. > > The behavior I expected was that "svn add *" would schedule a snapshot of the > entire directory tree. Of course, to actually make this happen, I had to use > the "svn add * --force" > option. It's also worth noting that the option "svn add * --depth infinity" > also did not add the files that were > buried in the subdirectores; they were not added to be included on the next > commit. > > Why would you have subversion skip a bunch of files? That makes no sense. > > The "import" command conversely, adds all the files in all the > subdirectories, when a new directory > is first brought under version control. > > It seems to me, the default behavior should be the obvious behavior. Or maybe > there > is more that I don't yet understand. If so, I would like to hear. > > Thanks. It is great software. > > David Heitzman > > -- > Life moves on, whether we act as cowards, or heroes.
