Re: Log problem
Hi, Thank you for your reply. My folders are up to date in my working copy, but the log information is the same either when requested on working copy resources or when using the repository URLs. Is strange that there is a long time since I work with this working copy structure and suddenly something which worked fine seems to be broken. Have any idea about what else could trigger this behavior ?! Best Regards, Florin From: Ryan Schmidt subversion-20...@ryandesign.com To: Florin Avram avnyr...@yahoo.com Cc: users@subversion.apache.org Sent: Wed, November 3, 2010 4:10:52 PM Subject: Re: Log problem On Nov 3, 2010, at 05:54, Florin Avram wrote: I've run over a strange situation and want to know if this is OK to happen (in my opinion it shouldn't). These are the details: - one of our servers has a repository with Subversion 1.4 format - I have a working copy from a given repository path, let it be http://R/svn/repos/userguide; - in my working copy, one of the folders has an external folder X, pointing to http://R/svn/repos/branches/rel/doc; - I modify a file from the external folder X and commit it - when looking over the log information of the root of my working copy, there is no entry for the commit which I've just made (this is OK, I've committed to an external resource) - after, I look over the log information of the folder at which my working copy external folder targets. There is no information about my commit there either, which is strange, I've committed from my external folder which is pointing to this one. Is the folder up to date? Use svn up and try again. - the folder to which my working copy external folder is pointing was copied from another branch, and if I do a log on that branch (the original one), then I can see my commit, which again is strange: why the commit goes there and not to the HEAD of the branch to which my external folder is pointing. I don't know if the above information helps you somehow, but I would like to know if this would be possible and if this is a repository side problem, taking into account that the repository has an old version (1.4). I doubt any problem exists.
Re: Log problem
[small nit: please don't top-post on this list, i.e. put your reply at the bottom, or inline.] On Fri, Nov 5, 2010 at 9:22 AM, Florin Avram avnyr...@yahoo.com wrote: Hi, Thank you for your reply. My folders are up to date in my working copy, but the log information is the same either when requested on working copy resources or when using the repository URLs. Is strange that there is a long time since I work with this working copy structure and suddenly something which worked fine seems to be broken. Have any idea about what else could trigger this behavior ?! Best Regards, Florin From: Ryan Schmidt subversion-20...@ryandesign.com To: Florin Avram avnyr...@yahoo.com Cc: users@subversion.apache.org Sent: Wed, November 3, 2010 4:10:52 PM Subject: Re: Log problem On Nov 3, 2010, at 05:54, Florin Avram wrote: I've run over a strange situation and want to know if this is OK to happen (in my opinion it shouldn't). These are the details: - one of our servers has a repository with Subversion 1.4 format - I have a working copy from a given repository path, let it be http://R/svn/repos/userguide; - in my working copy, one of the folders has an external folder X, pointing to http://R/svn/repos/branches/rel/doc; - I modify a file from the external folder X and commit it - when looking over the log information of the root of my working copy, there is no entry for the commit which I've just made (this is OK, I've committed to an external resource) - after, I look over the log information of the folder at which my working copy external folder targets. There is no information about my commit there either, which is strange, I've committed from my external folder which is pointing to this one. Is the folder up to date? Use svn up and try again. - the folder to which my working copy external folder is pointing was copied from another branch, and if I do a log on that branch (the original one), then I can see my commit, which again is strange: why the commit goes there and not to the HEAD of the branch to which my external folder is pointing. This seems very strange. If you commit a change into an external, it should go exactly to that external, not to some other location of which your external location is a copy. Are you sure that the external property is set correctly? Can you provide more details? Maybe give the exact contents of the svn:externals property, and an overview of the repository structure (feel free to obfuscate any paths or other information that may be confidential)? Just a wild guess: the syntax for the svn:externals property has changed (in 1.5 I believe): the order of the URL and the target were reversed (among other things). See http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html. Could it be that your problem is caused because the externals definition is now interpreted differently than before (by a 1.5+ client, as opposed to a 1.4 client previously)? Cheers, -- Johan
Re: mergeinfo not inherrited when I thought it should
On Thu, Nov 4, 2010 at 2:00 PM, Pieter-Jan Busschaert pieterjan.busscha...@gmail.com wrote: Hello, There are a few things still not clear to me: 1) Before this svn update, svn stat -u shows nothing out-of-date, so it's strange that an update makes any difference. Try svn stat -v, and you'll see the different working revisions of the files and dirs in the working copy. It's the out-of-date working revision that is actually causing this. Updating it brings it all at the same level, so svn can be sure that it has consistent information. Yes, I noticed that. I had put the output of svn stat -v in the reproduction scenario. I am not really certain why you say so svn can be sure it has consistent information. I always thought if my working revision was = last changed revision, then I had everything up-to-date. [however, see below] 3) If I check the relevant svn:mergeinfo properties before / after this svn update, I see no changes at all. However, if I check with the svn mergeinfo command, then I do see a change after the update. What else is being used to calculate the actual mergeinfo? You should really read the entire section Mixed Revision Working Copies and Mergeinfo of the article http://www.collab.net/community/subversion/articles/merge-info.html. I think the example near the end of that section describes a very similar situation. I think you are seeing exactly the same thing here. OK, that was an interesting section to read. However, from my experience, the sentence Admittedly both of these example are a bit contrived, and you may never run into anything like them. is a bit far-fetched. Without the rule to only merge on top-level, you run into this frequently. Ok, maybe this is not that extremely rare (however, this is the first report I see about this on the users list, so it's not that common either). Now, I have been able to narrow down the necessary svn update a bit further. Same reproduction script as before, just before the bad second merge. r5 is the first merge which: (1) updated the file /branch/subdir/test.txt and (2) added mergeinfo on /branch. $ svn stat -u -v 6 6 pjbu trunk/subdir/test.txt 3 2 pjbu trunk/subdir 3 2 pjbu trunk 5 5 pjbu branch/subdir/test.txt 3 2 pjbu branch/subdir === this causes the wrong mergeinfo 5 5 pjbu branch 3 3 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r4 === was already merged, it is in svn:mergeinfo on /branch @ r5 r6 $ svn up -r 5 --depth=empty branch/subdir At revision 5. == doesn't change anything Yes it does. It changes the working revision of branch/subdir from 3 to 5. Since this update didn't bring in new explicit mergeinfo on branch/subdir, svn can now safely assume that the mergeinfo from /branch can be inherited (before this update, it could not be sure about that). $ svn stat -u -v 6 6 pjbu trunk/subdir/test.txt 3 2 pjbu trunk/subdir 3 2 pjbu trunk 5 5 pjbu branch/subdir === the last-commited rev in the repo also changed ??? Hm, maybe that's because it can now inherit the mergeinfo from /branch, which was introduced in r5. So in effect, this branch/subdir *was* changed in r5, namely it inherits new mergeinfo from branch. 5 5 pjbu branch/subdir/test.txt 5 5 pjbu branch 3 3 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r6 correct now Well, I can see how svn has trouble when merging into branch/subdir without that directory itself being atleast at the revision where the mergeinfo was added to its parent. However, there seems something strange with the notion of out-of-date on a directory. I thought the second column of revision numbers in svn stat -v was completely independent of the working copy status, but that doesn't seem to be the case. Indeed, the second column is only information present in the working copy (it doesn't contact the repository to see that the last changed rev over there is higher than what it has in the working copy). It's a pity all the improvements around tracking mergeinfo will only be included in 1.7, because I fear all the WC-NG developments will make our company even more reluctant to update to that version. Why? Because it's new technology, a rewrite of some piece that has already 10 years of maturity (and numerous bugfixes and optimizations) under its belt? And they fear a lot of instability because of this? If so, I can certainly understand this argument. New stuff
Re: Log problem
On Nov 5, 2010, at 05:05, Johan Corveleyn wrote: Just a wild guess: the syntax for the svn:externals property has changed (in 1.5 I believe): the order of the URL and the target were reversed (among other things). See http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html. Could it be that your problem is caused because the externals definition is now interpreted differently than before (by a 1.5+ client, as opposed to a 1.4 client previously)? The old externals syntax is still supported, but as of 1.5 an additional syntax is supported as well with the order reversed.
Re: apache coredump in mod_dav_svn
Perhaps you could also supply what your OS, Apache version, and Subversion version are? Are you up to Subversion 1.6.13, and did you build it yourself or are you using your particular OS's packaged version? On Wed, Nov 3, 2010 at 11:54 PM, Rob Kooper koo...@ncsa.illinois.edu wrote: I'm getting a core dump in mod_dav_svn, here is the backtrace: (gdb) bt full #0 0x7f6a31d5a9c3 in svn_stringbuf_dup () from /usr/lib/libsvn_subr-1.so.1 No symbol table info available. #1 0x7f6a325c7284 in ?? () from /usr/lib/apache2/modules/mod_dav_svn.so No symbol table info available. #2 0x7f6a327e11de in ?? () from /usr/lib/apache2/modules/mod_dav.so No symbol table info available. #3 0x7f6a327e2578 in ?? () from /usr/lib/apache2/modules/mod_dav.so No symbol table info available. #4 0x7f6a35516380 in ap_run_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:159 n = 3 rv = 963463992 #5 0x7f6a35519ce8 in ap_invoke_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:373 handler = 0x0 result = 0 old_handler = 0x7f6a327e8168 dav-handler ignore = value optimized out #6 0x7f6a355275e8 in ap_process_request (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:282 access_status = 963463992 #7 0x7f6a35524498 in ap_process_http_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/modules/http/http_core.c:190 r = 0x7f6a396d4bb8 csd = 0x0 #8 0x7f6a3551df38 in ap_run_process_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/server/connection.c:43 n = 2 rv = 963463992 #9 0x7f6a3552ce82 in process_socket (thd=value optimized out, dummy=value optimized out) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:544 current_conn = value optimized out conn_id = value optimized out csd = 23 sbh = 0x7f6a386592e8 #10 worker_thread (thd=value optimized out, dummy=value optimized out) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:894 process_slot = 0 thread_slot = 16 csd = 0x7f6a386590d8 bucket_alloc = value optimized out last_ptrans = value optimized out ptrans = 0x7f6a38659048 rv = value optimized out is_idle = value optimized out #11 0x7f6a34c532ff in ?? () from /usr/lib/libapr-1.so.0 No symbol table info available. #12 0x7f6a34a139ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #13 0x7f6a3477070d in clone () from /lib/libc.so.6 No symbol table info available. #14 0x in ?? () No symbol table info available. This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen: curl --request PROPFIND --header Depth: 1 https://host/svn/ The section from apache.conf is: Location /svn # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNParentPath /home/svn SVNListParentPath on /Location Is this a known issue or do I have something wrong. Rob -- Rob Kooper 1205 W. Clark St, MC-257 Urbana, IL 61801 217-333-3593 koo...@ncsa.illinois.edu
Re: apache coredump in mod_dav_svn
Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500: I'm getting a core dump in mod_dav_svn, here is the backtrace: ... This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen: curl --request PROPFIND --header Depth: 1 https://host/svn/ The section from apache.conf is: Location /svn # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNParentPath /home/svn SVNListParentPath on /Location Is this a known issue or do I have something wrong. Thanks for the report. I can reproduce it with current trunk: (gdb) bt #0 0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518) at subversion/libsvn_subr/svn_string.c:509 #1 0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0) at subversion/mod_dav_svn/repos.c:4139 #2 0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064 #3 0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649 #4 0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158 #5 0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376 #6 0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282 #7 0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190 #8 0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43 #9 0x080beb5d in child_main (child_num_arg=value optimized out) at prefork.c:662 #10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707 #11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at prefork.c:983 #12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739
Re: mergeinfo not inherrited when I thought it should
$ svn up -r 5 --depth=empty branch/subdir At revision 5. == doesn't change anything Yes it does. It changes the working revision of branch/subdir from 3 to 5. Since this update didn't bring in new explicit mergeinfo on branch/subdir, svn can now safely assume that the mergeinfo from /branch can be inherited (before this update, it could not be sure about that). OK. But if svn merge already contacts the repository when it doesn't find any mergeinfo in the WC, then I think it could contact the repository to automatically check for the above case too. However, there seems something strange with the notion of out-of-date on a directory. I thought the second column of revision numbers in svn stat -v was completely independent of the working copy status, but that doesn't seem to be the case. Indeed, the second column is only information present in the working copy (it doesn't contact the repository to see that the last changed rev over there is higher than what it has in the working copy). Thanks for the clarification, I thought the combination of -u and -v would show me the state in the repository, but this is clearly not the case. I also noticed directories get the highest last-changed rev-number of any of their children, even if nothing really changed on the directory properties itself. These 2 things got me confused... It's a pity all the improvements around tracking mergeinfo will only be included in 1.7, because I fear all the WC-NG developments will make our company even more reluctant to update to that version. The rewrite was/is absolutely necessary to go forward. I know and I will try to keep some of these testcases around to check with 1.7. Kind regards, Pieter-Jan
mod_dav_svn segfaults upon PROPFIND to the SVNParentPath location (was: Re: apache coredump in mod_dav_svn)
Moving to d...@. (Please drop users@ from follow-ups.) Summary: segfault in mod_dav_svn with PROPFIND at the SVNParentPath location, reproducable with trunk. Daniel Shahaf wrote on Fri, Nov 05, 2010 at 14:03:26 +0200: Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500: I'm getting a core dump in mod_dav_svn, here is the backtrace: ... This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen: curl --request PROPFIND --header Depth: 1 https://host/svn/ The section from apache.conf is: Location /svn # Uncomment this to enable the repository DAV svn # Set this to the path to your repository SVNParentPath /home/svn SVNListParentPath on /Location Is this a known issue or do I have something wrong. Thanks for the report. I can reproduce it with current trunk: (gdb) bt #0 0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518) at subversion/libsvn_subr/svn_string.c:509 #1 0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0) at subversion/mod_dav_svn/repos.c:4139 #2 0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064 #3 0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649 #4 0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158 #5 0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376 #6 0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282 #7 0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190 #8 0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43 #9 0x080beb5d in child_main (child_num_arg=value optimized out) at prefork.c:662 #10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707 #11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at prefork.c:983 #12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739
svnsync checksum error
List, I've got about 20 repos that have been successfully syncing (with svnsync) to two read only copies for a few months. The r/w copy and both r/o copies are located on a local LAN (different subnets separated by firewalls). Today, the sync process started failing on 1 repo (all others were unaffected) on both r/o copies at the exact same time/same revision with errors similar to the following... Transmitting file data .svnsync: Base checksum mismatch on '/path/to/file/foo/bar': expected: 2f2e025c4c4855e7466799a877b3e23d actual: 272214b9518d352e16e7eeceeb22f573 I successfully removed the uncommitted transactions (svnadmin rmtxns reponame `svnadmin lstxns reponame`) and attempted the re-sync, to no avail. svnadmin verify returned no errors I ended up re-creating the r/o repo and then re-syncing all 65k commits to the repos (which takes a while...) Software binaries from Collabnet: r/w version = svn/svnsync, version 1.6.13 (r1002816) r/o 1 version = svn/svnsync, version 1.6.13 (r1002816) r/o 2 version = svn/svnsync, version 1.6.13 (r1002816) Is there a better approach to resolving the issue Am I running into a known issue? Any help/insight would be greatly appreciated. OSG
Svn externals question
Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few reuse repositories. We are attempting to be structured as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? Thanks for any help. Regards Steve Hutchinson FPGA Group Leader This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Svn externals question
In a checked-out working copy, svn status marks directories loaded by virtue of svn:externals with an 'X'. Other props, and finding even that one from the repository, requires scripting a loop to use svn plist or similar, I believe. Sent from my iPhone On Nov 5, 2010, at 9:50 AM, Hutchinson, Steve (UK) steven.hutchin...@mbda-systems.com wrote: Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few reuse repositories. We are attempting to be structured as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? Thanks for any help. Regards Steve Hutchinson FPGA Group Leader This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Svn externals question
On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote: Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few reuse repositories. We are attempting to be structured as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? The designers of the externals feature envisioned maybe a handful of external library dependencies that don't vary much over time. These are automatically pulled into a working copy, much like an automated svn checkout. But the design doesn't account for what happens when people start using svn:externals for variant management or large-scale component reuse. If you're pulling together project components from externals in various combinations, like lego blocks, or simply have many externals, don't use the svn:externals properties as the primary source of your configuration data. Do it the other way: Store your component configuration in a versioned file or even a database, and write a script to configure svn:externals properties based on that data. Maybe even add an automated check into the mix that makes sure the svn:externals in the repository's HEAD revision are in sync with your primary externals configuration source. You can query a file or a database easily to find out which components are used where. But svn properties haven't been designed for this use case. You cannot query a Subversion repository like you can query a database. Well, you could crawl the repository, but that's quite slow. Hope this helps, Stefan
Re: Svn externals question
If you do switch to the approach Stefan suggests (and I agree, it's probably more satisfactory) you also might want to use svn switch instead of the svn:externals. You'll still have the auditable, versioned definition of your canonical configuration (in the form of the script), but also there will be more freedom for variations, such as while preparing a new configuration. Sent from my iPhone On Nov 5, 2010, at 10:09 AM, Stefan Sperling s...@elego.de wrote: On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote: Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few reuse repositories. We are attempting to be structured as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? The designers of the externals feature envisioned maybe a handful of external library dependencies that don't vary much over time. These are automatically pulled into a working copy, much like an automated svn checkout. But the design doesn't account for what happens when people start using svn:externals for variant management or large-scale component reuse. If you're pulling together project components from externals in various combinations, like lego blocks, or simply have many externals, don't use the svn:externals properties as the primary source of your configuration data. Do it the other way: Store your component configuration in a versioned file or even a database, and write a script to configure svn:externals properties based on that data. Maybe even add an automated check into the mix that makes sure the svn:externals in the repository's HEAD revision are in sync with your primary externals configuration source. You can query a file or a database easily to find out which components are used where. But svn properties haven't been designed for this use case. You cannot query a Subversion repository like you can query a database. Well, you could crawl the repository, but that's quite slow. Hope this helps, Stefan
Re: Svn externals question
On Fri, Nov 05, 2010 at 11:03:58AM -0400, Jack Repenning wrote: If you do switch to the approach Stefan suggests (and I agree, it's probably more satisfactory) you also might want to use svn switch instead of the svn:externals. You'll still have the auditable, versioned definition of your canonical configuration (in the form of the script), but also there will be more freedom for variations, such as while preparing a new configuration. Right. But note that switched subtrees cannot come from a different repository.
Setting a web page at the repositories' parent URL
Hello, I have a question concerning the mod_dav_svn module that Apache use for accessing the repositories. According to the documentation, if I set a configuration like this one : Location /svn DAV svn SVNParentPath /var/lib/svn /Location ... I define a parent directory under which I can put all of my repositories. So I can access them like this : http://www.myserver.com/svn/my_first_repository/ http://www.myserver.com/svn/my_second_repository/ http://www.myserver.com/svn/my_third_repository/ http://www.myserver.com/svn/my_fourth_repository/ etc. But if I just type : http://www.myserver.com/svn/ I get a page like this one: -- Forbidden You don't have permission to access /svn/ on this server. Apache/2.2.9 (Debian) DAV/2 SVN/1.6.12 PHP/5.2.13 mod_perl/2.0.4 Perl/v5.10.0 Server at www.myserver.com Port 80 -- This is quite ugly, and I saw several SVN servers exhibiting this behavior. Is there a way to put a web page on this location? (for example a blank page, or a page with links to the only repositories that I want to be publicly accessible for reading) Best regards, GIngko
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 10:12, Gingko wrote: According to the documentation, if I set a configuration like this one : Location /svn DAV svn SVNParentPath /var/lib/svn /Location ... I define a parent directory under which I can put all of my repositories. So I can access them like this : http://www.myserver.com/svn/my_first_repository/ http://www.myserver.com/svn/my_second_repository/ http://www.myserver.com/svn/my_third_repository/ http://www.myserver.com/svn/my_fourth_repository/ etc. But if I just type : http://www.myserver.com/svn/ I get a page like this one: -- Forbidden You don't have permission to access /svn/ on this server. Apache/2.2.9 (Debian) DAV/2 SVN/1.6.12 PHP/5.2.13 mod_perl/2.0.4 Perl/v5.10.0 Server at www.myserver.com Port 80 -- This is quite ugly, and I saw several SVN servers exhibiting this behavior. Is there a way to put a web page on this location? (for example a blank page, or a page with links to the only repositories that I want to be publicly accessible for reading) The only option available is SVNListParentPath On which will give you a list of links to the available repositories.
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 10:36, Ryan Schmidt wrote: On Nov 5, 2010, at 10:12, Gingko wrote: Is there a way to put a web page on this location? (for example a blank page, or a page with links to the only repositories that I want to be publicly accessible for reading) The only option available is SVNListParentPath On which will give you a list of links to the available repositories. That is to say, SVNListParentPath is the only mod_dav_svn-specific option available to affect this. And there's also SVNIndexXSLT with which you can specify an XSLT stylesheet to change the appearance of that index. But you could probably make the web server deliver any other kind of page you wanted, by using the directives of the standard Apache modules (e.g. mod_alias, mod_rewrite, etc.).
Re: Svn externals question
On Fri, Nov 5, 2010 at 3:09 PM, Stefan Sperling s...@elego.de wrote: On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote: Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few reuse repositories. We are attempting to be structured as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? The designers of the externals feature envisioned maybe a handful of external library dependencies that don't vary much over time. These are automatically pulled into a working copy, much like an automated svn checkout. But the design doesn't account for what happens when people start using svn:externals for variant management or large-scale component reuse. If you're pulling together project components from externals in various combinations, like lego blocks, or simply have many externals, don't use the svn:externals properties as the primary source of your configuration data. Do it the other way: Store your component configuration in a versioned file or even a database, and write a script to configure svn:externals properties based on that data. Maybe even add an automated check into the mix that makes sure the svn:externals in the repository's HEAD revision are in sync with your primary externals configuration source. You can query a file or a database easily to find out which components are used where. But svn properties haven't been designed for this use case. You cannot query a Subversion repository like you can query a database. Well, you could crawl the repository, but that's quite slow. Hope this helps, Stefan For finding the folders that have the svn:externals property, how about: svn propget -R svn:externals TARGET where TARGET can be a working copy path or a url. For a url it will not be fast, but it works (for a working copy it works quite fast). I do agree with Stefan though, that it's best to have another canonical source for this kind of configuration data, especially if it starts becoming more and more complex, and to derive the externals configuration from that. Cheers, -- Johan
Re: Svn externals question
On Fri, Nov 5, 2010 at 9:49 AM, Hutchinson, Steve (UK) steven.hutchin...@mbda-systems.com wrote: Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? Not 100% clear what you're looking for. You could be looking for one of two things: 1). You have a project, and it has svn:externals set on certain folders. You want to find those folders. That's fairly easy to do with the svn propget. Go to the root of your project and run: $ svn propget -v -R svn:externals That will show you all the directories where svn:externals are set and directories are being pulled in. 2). You have a bunch of external projects, and want to know in what other projects they're being used. This is much more difficult since there's no way to see what projects are using a particular directory as an external project. The only thing I can think of is to run the svn propget on the entire repository and parse the output. -- David Weintraub qazw...@gmail.com
Re: Svn externals question
On Fri, Nov 5, 2010 at 10:09 AM, Stefan Sperling s...@elego.de wrote: The designers of the externals feature envisioned maybe a handful of external library dependencies that don't vary much over time. These are automatically pulled into a working copy, much like an automated svn checkout. But the design doesn't account for what happens when people start using svn:externals for variant management or large-scale component reuse. If you're pulling together project components from externals in various combinations, like lego blocks, or simply have many externals, don't use the svn:externals properties as the primary source of your configuration data. The big problem with svn:externals is that they don't version very well. Imagine I have a project called foo, and in the root directory, I set an svn:external property to pull in the trunk of module bar that contains certain routines I'm using: $ svn propset svn:externals bar /externals/bar/trunk When foo is ready for Release 1.0, I create a tag: $ svn copy svn://subversion/foo/trunk svn://subversion/foo/tags/REL-1.0 Everything is fine and dandy, but we found a few bugs, so we're going to create a Release 1.1 to fix those bugs. I create my 1.1 branch: $ svn copy svn://subversion/foo/tags/REL-1.0 svn://subversion/foo/branches/1.1 But, there's a problem. I discover that what is tagged as REL-1.0 isn't the code I released. In fact, all the difference between what has been tagged and what was released are in that bar subdirectory that was created by my svn:externals property. The problem is that the external directories themselves aren't tagged or branched when I did my tag or branch. Instead, the svn:external property itself was versioned, and if you have that pointing to just the branch or the trunk without a version number, that external directory can keep changing in the tag. You can partially solve that problem by making sure your svn:external property points to a specific tag and/or a specific version of the external directory. But, then you have to start keeping the svn:external tags up to date which can be a headache if you have a lot of them. When I first started using Subversion, I though svn:externals was a great feature. But I quickly discovered what a mess they can create. I now take the approach of thinking of my externals as releasable components that are also versioned and released, and I put them into a release repository where various projects can import a specific revision of that component. This makes it much easier for developers to track what particular version of that component they're using. -- David Weintraub qazw...@gmail.com
Re: Svn externals question
On Nov 5, 2010, at 11:54, David Weintraub wrote: The big problem with svn:externals is that they don't version very well. The problem is that the external directories themselves aren't tagged or branched when I did my tag or branch If this is important to you, then you should use the svncopy.pl script to create your tags because this is exactly what it takes care of for you.
RE: Setting a web page at the repositories' parent URL
Hi Gingko I have had success setting up several repositories in Apache as follows... In the httpd-subversion.conf file, I have the various repositories defined like this. Location /svn/repo1 SVNPath /path/to/repo1 . . . /Location Location /svn/repo2 SVNPath /path/to/repo2 . . . /Location Location /svn/repo3 SVNPath /path/to/repo3 . . . /Location Then when I hit http://server/svn/repo1, I get access to repo1, I hit http://server/svn/repo1, I get access to repo2, etc. If you use SVNParentPath instead of SVNPath, you can have issues so this seems to work well for me. As far as a web page goes, you could create a custom index.html that has all the links to the various repositories so if users just goes right to http://server, they see the custom index.html which has all the repository links. There should already be a default index.html in the Apache /htdocs folder that has It Works! in it. You could just back that one up and replace it with a new index.html that has the links to all the repositories. Regards, Mark -Original Message- From: Gingko [mailto:from_tig...@nospam.homelinux.org] Sent: Friday, November 05, 2010 11:12 AM To: Subversion User List Subject: Setting a web page at the repositories' parent URL Hello, I have a question concerning the mod_dav_svn module that Apache use for accessing the repositories. According to the documentation, if I set a configuration like this one : Location /svn DAV svn SVNParentPath /var/lib/svn /Location ... I define a parent directory under which I can put all of my repositories. So I can access them like this : http://www.myserver.com/svn/my_first_repository/ http://www.myserver.com/svn/my_second_repository/ http://www.myserver.com/svn/my_third_repository/ http://www.myserver.com/svn/my_fourth_repository/ etc. But if I just type : http://www.myserver.com/svn/ I get a page like this one: -- Forbidden You don't have permission to access /svn/ on this server. Apache/2.2.9 (Debian) DAV/2 SVN/1.6.12 PHP/5.2.13 mod_perl/2.0.4 Perl/v5.10.0 Server at www.myserver.com Port 80 -- This is quite ugly, and I saw several SVN servers exhibiting this behavior. Is there a way to put a web page on this location? (for example a blank page, or a page with links to the only repositories that I want to be publicly accessible for reading) Best regards, GIngko
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 13:50, Eramo, Mark wrote: I have had success setting up several repositories in Apache as follows... In the httpd-subversion.conf file, I have the various repositories defined like this. Location /svn/repo1 SVNPath /path/to/repo1 . . . /Location Location /svn/repo2 SVNPath /path/to/repo2 . . . /Location Location /svn/repo3 SVNPath /path/to/repo3 . . . /Location Then when I hit http://server/svn/repo1, I get access to repo1, I hit http://server/svn/repo1, I get access to repo2, etc. That's exactly what SVNParentPath is supposed to let you do more easily and concisely. As far as a web page goes, you could create a custom index.html that has all the links to the various repositories so if users just goes right to http://server, they see the custom index.html which has all the repository links. There should already be a default index.html in the Apache /htdocs folder that has It Works! in it. You could just back that one up and replace it with a new index.html that has the links to all the repositories. That's exactly what SVNListParentPath is for. If you use SVNParentPath instead of SVNPath, you can have issues so this seems to work well for me. What issues are you referring to?
RE: Setting a web page at the repositories' parent URL
I had issues with SVNParentPath but I think it was how I set it up. When I set it up the way I showed, it worked well. When I was doing this, I did not find docs that explained SVNParentPath well enough to me so maybe that is why I had the setup issues. Regards, Mark -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Friday, November 05, 2010 3:05 PM To: Eramo, Mark Cc: Subversion User List Subject: Re: Setting a web page at the repositories' parent URL On Nov 5, 2010, at 13:50, Eramo, Mark wrote: I have had success setting up several repositories in Apache as follows... In the httpd-subversion.conf file, I have the various repositories defined like this. Location /svn/repo1 SVNPath /path/to/repo1 . . . /Location Location /svn/repo2 SVNPath /path/to/repo2 . . . /Location Location /svn/repo3 SVNPath /path/to/repo3 . . . /Location Then when I hit http://server/svn/repo1, I get access to repo1, I hit http://server/svn/repo1, I get access to repo2, etc. That's exactly what SVNParentPath is supposed to let you do more easily and concisely. As far as a web page goes, you could create a custom index.html that has all the links to the various repositories so if users just goes right to http://server, they see the custom index.html which has all the repository links. There should already be a default index.html in the Apache /htdocs folder that has It Works! in it. You could just back that one up and replace it with a new index.html that has the links to all the repositories. That's exactly what SVNListParentPath is for. If you use SVNParentPath instead of SVNPath, you can have issues so this seems to work well for me. What issues are you referring to?
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 14:11, Eramo, Mark wrote: Ryan Schmidt wrote: On Nov 5, 2010, at 13:50, Eramo, Mark wrote: I have had success setting up several repositories in Apache as follows... In the httpd-subversion.conf file, I have the various repositories defined like this. Location /svn/repo1 SVNPath /path/to/repo1 . . . /Location Location /svn/repo2 SVNPath /path/to/repo2 . . . /Location Location /svn/repo3 SVNPath /path/to/repo3 . . . /Location Then when I hit http://server/svn/repo1, I get access to repo1, I hit http://server/svn/repo1, I get access to repo2, etc. That's exactly what SVNParentPath is supposed to let you do more easily and concisely. As far as a web page goes, you could create a custom index.html that has all the links to the various repositories so if users just goes right to http://server, they see the custom index.html which has all the repository links. There should already be a default index.html in the Apache /htdocs folder that has It Works! in it. You could just back that one up and replace it with a new index.html that has the links to all the repositories. That's exactly what SVNListParentPath is for. If you use SVNParentPath instead of SVNPath, you can have issues so this seems to work well for me. What issues are you referring to? I had issues with SVNParentPath but I think it was how I set it up. When I set it up the way I showed, it worked well. When I was doing this, I did not find docs that explained SVNParentPath well enough to me so maybe that is why I had the setup issues. For what you showed, it should simply be: Location /svn/ SVNPath /path/to/ SVNListParentPath On /Location That's it.
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 14:19, Ryan Schmidt wrote: For what you showed, it should simply be: Location /svn/ SVNPath /path/to/ SVNListParentPath On /Location And if I'd type it correctly, it would be: Location /svn/ DAV svn SVNParentPath /path/to/ SVNListParentPath On /Location
Re: Setting a web page at the repositories' parent URL
On Nov 5, 2010, at 14:38, Gingko wrote: That's exactly what SVNParentPath is supposed to let you do more easily and concisely. Except that it locks the possibility to have any other (custom) content at the parent path. As I said earlier in the thread, I'll guess you can already achieve that using mod_rewrite or possibly mod_alias.
Re: Setting a web page at the repositories' parent URL
- Original Message - From: Ryan Schmidt subversion-20...@ryandesign.com To: Gingko from_tig...@nospam.homelinux.org Cc: Subversion User List users@subversion.apache.org Sent: Friday, November 05, 2010 8:48 PM Subject: Re: Setting a web page at the repositories' parent URL On Nov 5, 2010, at 14:38, Gingko wrote: That's exactly what SVNParentPath is supposed to let you do more easily and concisely. Except that it locks the possibility to have any other (custom) content at the parent path. As I said earlier in the thread, I'll guess you can already achieve that using mod_rewrite or possibly mod_alias. Of course. But I would say that this is a little less .. neat. (and also this will probably mean that I will have to put this page on another web site, or in a parent directory of the parent directory if there is one, as I will probably not be able to rewrite in such a way that I could access a page physically located at the SVN parent directory) Gingko
Only two Windows binary distribution support SASL encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have the Win 2003 server set up with SASL and encryption, as stated earlier this week. The relevant portion of svnserve.conf: [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 and svn.conf: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 sasldb_path: C:\Subversion\conf\sasldb I tried all the Windows binaries on the binaries download page. Only SlikSVN and WANdisco are able to talk to the repository. All other fail with svn: Cannot negotiate authentication mechanism JAB - -- John Alan Belli jabe...@pobox.com http:// coming soon (_...@___#PGP DH/DSS Key ID: 0x9F9A5233 RSA Key ID: 0xFD7399CD U/~ O- Available by finger and on various keyservers -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) - WinPT 1.4.2 Charset: UTF-8 iEYEARECAAYFAkzUZ60ACgkQ2IsOhZ+aUjPytgCg23vT0IeZf/faepHaltdP7Uxa BWEAoJz3/TUyINwgpoLYGLwtkhR1jx28 =xTV3 -END PGP SIGNATURE-
Re: Only two Windows binary distribution support SASL encryption?
That seems like reasonable information to add to the download page. John Alan Belli wrote on Fri, Nov 05, 2010 at 16:23:51 -0400: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have the Win 2003 server set up with SASL and encryption, as stated earlier this week. The relevant portion of svnserve.conf: [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 and svn.conf: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 sasldb_path: C:\Subversion\conf\sasldb I tried all the Windows binaries on the binaries download page. Only SlikSVN and WANdisco are able to talk to the repository. All other fail with svn: Cannot negotiate authentication mechanism JAB - -- John Alan Belli jabe...@pobox.com http:// coming soon (_...@___#PGP DH/DSS Key ID: 0x9F9A5233 RSA Key ID: 0xFD7399CD U/~ O- Available by finger and on various keyservers -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) - WinPT 1.4.2 Charset: UTF-8 iEYEARECAAYFAkzUZ60ACgkQ2IsOhZ+aUjPytgCg23vT0IeZf/faepHaltdP7Uxa BWEAoJz3/TUyINwgpoLYGLwtkhR1jx28 =xTV3 -END PGP SIGNATURE-
Re: Only two Windows binary distribution support SASL encryption?
I have the Win 2003 server set up with SASL and encryption, as stated earlier this week. The relevant portion of svnserve.conf: [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 and svn.conf: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 sasldb_path: C:\Subversion\conf\sasldb I tried all the Windows binaries on the binaries download page. Only SlikSVN and WANdisco are able to talk to the repository. All other fail with svn: Cannot negotiate authentication mechanism When I have tested the CollabNet binaries in the past they supported this fine. The Cyrus SASL stuff requires registry entries to work properly. If you are trying all of these from the same workstation are you checking those entries? I know I have Subclipse users that use SASL via installing those binaries. I do not know which options they use. In general, I think it was a mistake that we ever allowed the SASL stuff into our code base. The required dependencies are poorly documented which just makes SVN look bad and it does not accomplish the main goal virtually every user wanted, which was to connect to Active Directory. IMO, Apache server is still the best way to go. -- Thanks Mark Phippard http://markphip.blogspot.com/
Promoting a mirror repository as a source repository
Hello again, I have a (now theoretical) question : Suppose I have a repository that is a mirror repository of a remote source repository, regularly synced using svnsync. Suppose now that the source repository become broken or deleted for any reason (server breakdown, fire, etc) So the only available copy of the repository is now the synced mirror repository. How could I promote my mirror repository in order to have it becoming the new source repository on the mirror server or on another server ? (I think that just using the mirror repository without change is not enough as it contains somewhere inside it information about the old source repository, given at the beginning by svnsync initialize, which would certainly need to be removed) Gingko
Re: Promoting a mirror repository as a source repository
Greetings, Gingko! I have a (now theoretical) question : Suppose I have a repository that is a mirror repository of a remote source repository, regularly synced using svnsync. Suppose now that the source repository become broken or deleted for any reason (server breakdown, fire, etc) So the only available copy of the repository is now the synced mirror repository. How could I promote my mirror repository in order to have it becoming the new source repository on the mirror server or on another server ? (I think that just using the mirror repository without change is not enough as it contains somewhere inside it information about the old source repository, given at the beginning by svnsync initialize, which would certainly need to be removed) svn help switch http://svnbook.org/ -- WBR, Andrey Repin (anrdae...@freemail.ru) 06.11.2010, 3:29 Sorry for my terrible english...
Re: Promoting a mirror repository as a source repository
- Original Message - From: Andrey Repin anrdae...@freemail.ru To: Gingko from_tig...@nospam.homelinux.org; users@subversion.apache.org Sent: Saturday, November 06, 2010 1:30 AM Subject: Re: Promoting a mirror repository as a source repository Greetings, Gingko! I have a (now theoretical) question : Suppose I have a repository that is a mirror repository of a remote source repository, regularly synced using svnsync. Suppose now that the source repository become broken or deleted for any reason (server breakdown, fire, etc) So the only available copy of the repository is now the synced mirror repository. How could I promote my mirror repository in order to have it becoming the new source repository on the mirror server or on another server ? (I think that just using the mirror repository without change is not enough as it contains somewhere inside it information about the old source repository, given at the beginning by svnsync initialize, which would certainly need to be removed) svn help switch http://svnbook.org/ Thank you very much for your answer, but I'm sorry, this is not an answer to my question. svn switch is about changing URLs in working copies, I know how to do this (actually I made several of these changes today). But what I want to know is what I have to do on the REPOSITORY side. Gingko
RE: Promoting a mirror repository as a source repository
This is doable (I've done it). The shadow repository needs to have the same UUID as the source, and you either have to repoint the DNS at it or svn switch all existing clients. See Andrey's link for the skinny. Tony. -Original Message- From: Gingko [mailto:from_tig...@nospam.homelinux.org] Sent: 05 November 2010 23:50 To: Subversion User List Subject: Promoting a mirror repository as a source repository Hello again, I have a (now theoretical) question : Suppose I have a repository that is a mirror repository of a remote source repository, regularly synced using svnsync. Suppose now that the source repository become broken or deleted for any reason (server breakdown, fire, etc) So the only available copy of the repository is now the synced mirror repository. How could I promote my mirror repository in order to have it becoming the new source repository on the mirror server or on another server ? (I think that just using the mirror repository without change is not enough as it contains somewhere inside it information about the old source repository, given at the beginning by svnsync initialize, which would certainly need to be removed) Gingko __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Promoting a mirror repository as a source repository
Plus, you need to set a number of properties on the zeroeth revision of the target repository (if I recall correctly) and add a hook script for the sync user to be allowed to modify revision commit text in order for svnsync to run successfully. (And delete the revo #0 properties when you're done, though I don't think that was essential). Look in the red bean book at svnsync. Tony. -Original Message- From: Gingko [mailto:from_tig...@nospam.homelinux.org] Sent: 06 November 2010 01:02 To: Subversion User List Subject: Re: Promoting a mirror repository as a source repository - Original Message - From: Andrey Repin anrdae...@freemail.ru To: Gingko from_tig...@nospam.homelinux.org; users@subversion.apache.org Sent: Saturday, November 06, 2010 1:30 AM Subject: Re: Promoting a mirror repository as a source repository Greetings, Gingko! I have a (now theoretical) question : Suppose I have a repository that is a mirror repository of a remote source repository, regularly synced using svnsync. Suppose now that the source repository become broken or deleted for any reason (server breakdown, fire, etc) So the only available copy of the repository is now the synced mirror repository. How could I promote my mirror repository in order to have it becoming the new source repository on the mirror server or on another server ? (I think that just using the mirror repository without change is not enough as it contains somewhere inside it information about the old source repository, given at the beginning by svnsync initialize, which would certainly need to be removed) svn help switch http://svnbook.org/ Thank you very much for your answer, but I'm sorry, this is not an answer to my question. svn switch is about changing URLs in working copies, I know how to do this (actually I made several of these changes today). But what I want to know is what I have to do on the REPOSITORY side. Gingko __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
