Re: How to accept ~ (obstructed by item of a different kind) status files?
Yeah, I do:
mv file d
svn remove file
mv d !$
svn add !$
There might be something simpler, I'm not sure, and some days I think I
should put that into a script, so I don't have to retype it, but how often
do I need it...
(slightly off-topic, I did finally write a related script to do:
"svn add `svn stat | grep ^? | awk '{print $2}'`; svn commit -m asdasd"
that I was typing multiple times a day.)
On Tue, 21 Feb 2023, Sean McBride wrote:
Hi all,
Today I hit something I never saw before: a ~ in svn status output.
Indeed, a file that is a symlink in the repo was (deliberately) changed to a
plain file in my working copy. I appreciate that this could be a mistake
generally, but when it's deliberate, how do I signal to svn that it's ok?
I guess I could always: remove, commit, re-add, commit, but can it not be done
otherwise?
Thanks,
Sean
--
Jon Daley
https://jon.limedaley.com
~~
So, on Wednesday, we will go into more depth in this...
or at least repeat it.
-- Dr. Langevin
Re: Is it possible to export multiple files in one command?
I don't believe it is possible - you can export a file or a whole directory. You could export the tree with one command and then move/cherry pick the files you want afterwards. On Sat, 21 Jan 2023, Bo Berglund wrote: I have a script, which is used in our installer creation process and it works as follows (on Windows): - Create a new target directory - Run svn commands to get the needed files into that dir - Run svn command to download the installer engine binary into its own dir - Run svn command to download the installer script itself - Start the installer engine with the script as argument This produces a new installation file in the installers directory. The svn command I am using is svn export since I don't want to create a versioned container and I also want to collect files from various different locations including documentation which will be part of the installer. What I would like to know is if there is an svn export command switch of some kind that can be used to export a set of files in one go if they reside in the same subversion directory? Right now I am repeating the following typical sequence, where the svn commands have to be run *inside* the target directory (variable SVNREPO has been set to the repository URL earlier): if EXIST Manager rmdir /s /q Manager mkdir Manager cd Manager svn export %SVNREPO%/Manager.exe .\ if errorlevel 1 goto error svn export %SVNREPO%/ssleay32.dll .\ if errorlevel 1 goto error svn export %SVNREPO%/libeay32.dll .\ if errorlevel 1 goto error svn export %SVNREPO%/doc/Manager_instructions.pdf .\ So to get these 4 files I have to issue 4 different svn commands... And I have had to create the target dir and move into it before doing this because otherwise the command instead of creating a subdir to stuff the file into exports the source file into a file named as the directory it is supposed to go into... Example: svn --force export %SVNREPO%/ssleay32.dll TargetDir This creates a *file* TargetDir with the content of ssleay32.dll instead of ssleay32.dll inside of TargetDir I would like to use a single svn command per source dir and get all the needed files from there at the same time according to a supplied list. Is this possible at all? -- Jon Daley https://jon.limedaley.com ~~ A man full of hope will be full of action. -- Thomas Brooks
Re: Unable to pull full commit history; Malformed XML not well-formed (invalid token)
Interesting. I can confirm the behavior (I have the same version as you). Unfortunately, I can't help you. Google seems to say the repo is corrupted, and needs to be fixed. On Thu, 29 Sep 2022, Carl Henrik Bernhoft wrote: Using SVN version: svn, version 1.14.1 (r1886195) compiled May 21 2022, 10:52:35 on x86_64-pc-linux-gnu. I tried pulling the commit log from https://github.com/haskell/random/branches/master but the process snags on https://github.com/haskell/random/commit/a44b801ab0033970660396a42462c4f7b4df56bb which corresponds to revision 897. The error is reproducible from the command line with svn log --xml -r897 https://github.com/haskell/random/branches/master The output is svn: E175009: The XML response contains invalid XML svn: E130003: Malformed XML: not well-formed (invalid token) at line 8 I was expecting control characters to be stripped, fuzzified or otherwise handled. The offending line in the commit, when printed with 'git log' displays as: 'Merged Martin SjA?gren's patch for multiline descriptionsb' which looks like reasonable output by comparison. I'm saw that handling unicode and control characters was a topic of discussion years ago but this case looks like a bug to me. It doesn't seem reasonable for the process to crash when pulling a remote commit log of a repo I don't own/control. -- Jon Daley https://jon.limedaley.com ~~ Live your life around the word of God and especially the Gospel. -- Greg Gill
Re: Problem about svnadmin load
Your command looks wrong to me. Having both jobs background themselves but the one wants the return code of the first seems like it wouldn't work. Maybe you didn't mean the && as a literal command, and you ran both jobs independently, and so all & and && should be removed? (I actually had to go try it myself because I wasn't sure how that would work, but, on my shell (bash) it gives a syntac error with the & inside single quotes) On Fri, 9 Sep 2022, 李斌 wrote: Hi There is a problem when load file via 'svnadmin load'. Command: 'nohup svnadmin load /data/UEProject < /data/UEProject-clear.svn > ./nohup.log 2>&1 &'. UEProject-clear.svn is a dump file generated by 'nohup svnadmin dump /root/SVN/UEProject > /data/UEProject.svn &' && 'nohup grep --binary-files=text -v '^* Dumped revision' ./UEProject.svn > ./UEProject-clear.svn &'. But when the file be loaded, I get the following error log from nohup.log. * adding path : UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/FeaturePack/manifest.json ... done. * adding path : UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media ... done. * adding path : UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media/VehicleAdv.png ... done. * adding path : UnrealEngine/4.26.2/Templates/TemplateResources/Standard/VehicleAdv/Media/VehicleAdv_Preview.png ... done. * adding path : UnrealEngine/4.26.2/UE4.sln ... done. * adding path : UnrealEngine/4.26.2/UE4Games.uprojectdirs ... done. * adding path : UnrealEngine/4.26.2/cpp.hint ... done. svnadmin: E140001: Unrecognized record type in stream svn, version 1.8.10 (r1615264) can you tell me how to resolve it? Best regards Lee
Re: Windows, svn propset svn:ignore *
I don't use Windows, so I can't help you on the escaping of the *, but I often use propedit, rather than propset (partly because I can never remember the order of the directory and the property value), so that would be easy enough for a one-off solution. Also, if you are using TortoiseSVN, can't you just right-click the directory and set the property that way and avoid the command-line usage entirely? On Fri, 26 Aug 2022, Daniel Sahlberg wrote: Hi, Using Subversion "trunk" on Windows built from TortoiseSVN. I would like to set the svn:ignore property to * on a certain directory. (I'm trying to ignore everything since I'd only want to explicitly add a few subdirectories). I thought this would do the trick C:\wc>svn propset svn:ignore * directoryname But alas it expands the * to all files in the current directory. I'd like to quote the * so the property is set to exactly *. I've found ways to quote the * (for example '*') but in those cases the property is set to also include the quotes. I've digged around and found a few messages in the archive indicating that Subversion on Windows is using setargv.obj and then the following thread on Stackoverflow [1] indicating that setargv.obj doesn't have a way to avoid wildcard expansion. Does anyone have a trick up the sleve? The following seems to work but it feels a bit unintuitive: echo * | svn propset -F - svn:ignore directoryname Kind regards, Daniel [1] https://stackoverflow.com/questions/47512829/is-it-possible-to-quote-escape-command-line-arguments-on-windows-while-linking-s -- Jon Daley https://jon.limedaley.com ~~ You're just jealous because the voices are talking to me.
Re: Invalid cross-link error when have a mounted subdirectory
On Mon, 8 Aug 2022, Daniel Shahaf wrote: Jon Daley via users wrote on Mon, Aug 08, 2022 at 05:12:37 -0400: Which version are you using, and on which operating system? Debian Bullseye 11.4. Subversion version 1.14.1 (r1886195). I had assumed this would be a known issue on a new version, so I hadn't looked into it further, but I have another system with the exact same version, but it works, so it must be a different of the repo or something? /.svn/format is 12 for both. The term is "working copy". The format number is given by `sqlite3 .svn/wc.db 'pragma user_version;'`. Yes, I did know that and wasn't precise - thanks. user_version is 31 for both. /etc/subversion/config and ~/.subversion/config are all empty. Climbing up the directory tree past mountpoints is... well, it's a bit dangerous. I understand, and I saw some people using removable drives, which sounds dangerous to me. I don't see any issues with permanently mounted drives; I understand there is probably a performance increase by doing some sort of rename or hard-link or something that only works on one filesystem, but it'd be nice to either detect that it is across filesystems (which would reduce the performance increase) or have a config setting that puts it in slow mode. I suspect it's done this way not for performance reasons but in order to take advantage of rename(2)'s atomicity guarantees. E.g., that's why an 'update' that's SIGKILLed partway, and leaves some items with 'L' in `svn status`, won't leave unversioned files or half-written versioned files behind. Yes, probably true. I just noticed that I reported this same bug years ago, and it was "resolved" by fixing the documentation, so I guess that is the end. It is interesting that it works on some systems. Presumably rename(2) doesn't return an error on those systems. Yeah, it must be, but given that the systems are so similar, I wonder what the difference is. The one that is broken is an AWS lightsail instance, and the other is my own physical RAID5 hardware, same drive, but different partitions, so perhaps that is why it works. I have gotten it to work this morning by doing a sparse checkout up to the mount point and then setting the depth on the mount point to infinity, and I've tested various operations trying to break it, and I couldn't. I also tried svn:externals, but referring to the direct child path, and subversion (rightly so) doesn't like that. -- Jon Daley https://jon.limedaley.com ~~ Use of excessive, unnecessary, commas, has always been, one of my, pet peeves.
Re: Invalid cross-link error when have a mounted subdirectory
On Sun, 7 Aug 2022, Nico Kadel-Garcia wrote: On Sun, Aug 7, 2022 at 8:40 AM Jon Daley via users wrote: I'm not sure what version this change happened in, but I used to be able to have my /home directory mounted and use subversion commands in my home directory, even though the .svn directory exists at /.svn Which version are you using, and on which operating system? Debian Bullseye 11.4. Subversion version 1.14.1 (r1886195). I had assumed this would be a known issue on a new version, so I hadn't looked into it further, but I have another system with the exact same version, but it works, so it must be a different of the repo or something? /.svn/format is 12 for both. /etc/subversion/config and ~/.subversion/config are all empty. Climbing up the directory tree past mountpoints is... well, it's a bit dangerous. I understand, and I saw some people using removable drives, which sounds dangerous to me. I don't see any issues with permanently mounted drives; I understand there is probably a performance increase by doing some sort of rename or hard-link or something that only works on one filesystem, but it'd be nice to either detect that it is across filesystems (which would reduce the performance increase) or have a config setting that puts it in slow mode. I also realized after my first posting that I can probably checkout /home separately from the / repo, which will fix the problem, I think. I just noticed that I reported this same bug years ago, and it was "resolved" by fixing the documentation, so I guess that is the end. It is interesting that it works on some systems. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766285 https://lists.apache.org/thread/8qggy35hbft1q88jjqnyjlkb49pvr0zr -- Jon Daley https://jon.limedaley.com ~~ Just because something is tradition doesn't make it right. -- Anthony D'Angelo
Invalid cross-link error when have a mounted subdirectory
I'm not sure what version this change happened in, but I used to be able to have my /home directory mounted and use subversion commands in my home directory, even though the .svn directory exists at /.svn But, today, I installed a new server, and whenever I use subversion inside my home directory, I get: /home/mail#svn copy svn+ssh://svn@ASDASDASD . svn: E155009: Failed to run the WC DB work queue associated with '/home/mail', work item 3470 (file-install home/mail/.no-spam-check 1 0 1 1) svn: E18: Can't move '/.svn/tmp/svn-U1XHuf' to '/home/mail/.no-spam-check': Invalid cross-device link Is there a way to make subversion not assume its tmp directory is on the same disk as the working directory?
svn_load_dirs doesn't support filenames with @ in
Hi,
It seems svn_load_dirs.pl doesn't support filenames with @ in. You get an
error such as:
's...@2x.png': a peg revision is not allowed here
This patch adds @ to the end of the filename, to make it work.
Cheers,
Jon
--- svn_load_dirs.pl.in.old.txt 2018-08-21 09:33:02.557893300 +0100
+++ svn_load_dirs.pl.in 2018-08-21 09:33:12.339005700 +0100
@@ -1203,6 +1203,12 @@ while (defined (my $load_dir = &get_next
print $handle $property_value;
close($handle);
+# Check for filenames containing svn rev character @. If it
+# contains one, add @ to end of filename
+if (index($add_file, '@') != -1) {
+$add_file = $add_file . '@';
+}
+
read_from_process($svn,
'propset',
$property_name,
Possible bug in subversion
Hello, We use subversion on AIX 6.1 and it works perfectly! But on AIX 7.1 we get a Segmention fault(coredump) using svn co. We have tried several of the aix 7.1 rpm supplied from perlz. Is this a known bug? test30:/home/rumo/tmp> svn co http://tvinnsvn:8080/svn/tvinn/trunk/dev/felles Authentication realm: <http://tvinnsvn:8080> AD-Subversion Username: rumo Password for 'rumo': --- ATTENTION! Your password for authentication realm: <http://tvinnsvn:8080> AD-Subversion can only be stored to disk unencrypted! You are advised to configure your system so that Subversion can store passwords encrypted, if possible. See the documentation for details. You can avoid future appearances of this warning by setting the value of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/.subversion/servers'. --- Store password unencrypted (yes/no)? yes Segmentation fault(coredump) Jon-Erik TYVAND Infrastructure Engineer [Sopra Steria] Sopra Steria Biskop Gunnerus´ gate 14A 0051 Oslo - Norway Mobile: +47 40 86 82 48 j...@soprasteria.com<mailto:j...@soprasteria.com> - www.soprasteria.no<http://www.soprasteria.no/> The content of this message may be confidential, legally privileged and protected by law. Unauthorized use, copying or disclosure of any of it may be unlawful. If you are not the intended recipient please notify the sender and remove it from your system. While attachments to this e-mail are checked for viruses, we do not accept any liability for any damage sustained by viruses. Before printing, think about the environment.
Subversion exception: assertion failed (svn_dirent_is_absolute(local_abspath))
Howdy. I was attempting to use TortoiseSVN to view the differences made in the history of a specific file, when I received the following exception: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8443: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- I can find another instance of this being reported ( http://svn.haxx.se/tsvnusers/archive-2013-01/0123.shtml) but this specific problem does not seem to be applicable to my scenario -- specifically, I do not have a directory named "c:". Normally I use a VPN to connect to my work's network, and from there I can access the remote repo. However, in this instance--when I tried to obtain the file history--I was NOT connected to the VPN. When I reconnect to the VPN, I am able to get the file history; when I disconnect, I see the exception as above. Let me know if I can offer any other information. Cheers, Jon
Re: Directory Already Added Bug?
Bump! On 30 January 2012 16:08, Jon Hardcastle wrote: > Hi, > > I have an issue where by i am trying to merge a directory structure from a > into b. > > One of the changes in that structure is that a directory that is already > present in b has been deleted and re-added in a. > > Hence I am trying to merge in the re-add. The only flagging of this I see is > a tree conflict telling it was already added and the ONLY option is 'Keep > the local directory' which is unlikely to be the desired actions since one > went to the trouble of merging a into b perhaps one might want the 'already > added' contents from a? instead of the statusquo of b? > > Is this correct? > > -- > -- > N: Jon Hardcastle > E: j...@ehardcastle.com > Q: The avalanche has already started. It is too late for the pebbles to > vote. -- -- N: Jon Hardcastle E: j...@ehardcastle.com Q: The avalanche has already started. It is too late for the pebbles to vote.
Re: Unable to checkout/add hidden files to repo
I had the same problem with both client version 1.5.1 that's installed on the server and 1.6.12 that's on my laptop (ubuntu 11.10) . This is an old server still running debian lenny, so it has not gotten many updates lately. I don't really understand how this is just now coming up as a problem. its possible that this has been happening for the last 2 years and no one noticed, but its very unlikely. we run over 50 projects out of this repo and all have hidden files like this in them. Either way I'm glad i was able to figure it out. it was about to be a long day if i didn't. I was planning on moving our repo this year anyways to a newer version of svn. Now I think i'll make that a higher priority. Thanks guys. On Tue, Jan 31, 2012 at 8:33 AM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Jan 31, 2012, at 07:18, Jon Grimes wrote: > > > You guys were right. I found the below line in my httpd.conf with a > note saying i added it in April of 2010 > > > > RedirectMatch 404 /\\..*(/.*|$) > > > > I don't understand how I'm just now having this problem though. Doesn't > make any sense. > > You mentioned server version 1.5.1 but not client version. Subversion 1.7 > includes a new http implementation which is different from the old > Subversion 1.6-and-earlier http implementation; I'm not sure if that > requires a 1.7 server as well. If so, then there's still the serf vs neon > difference; Subversion clients can use either, and they behave differently. > > >
Re: Unable to checkout/add hidden files to repo
You guys were right. I found the below line in my httpd.conf with a note saying i added it in April of 2010 RedirectMatch 404 /\\..*(/.*|$) I don't understand how I'm just now having this problem though. Doesn't make any sense. Thanks for you help. On Tue, Jan 31, 2012 at 8:05 AM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > On Jan 31, 2012, at 06:47, Jon Grimes wrote: > > On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote: > >> Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500: > >>> Essentially my repository wont let me check out or commit any hidden > files. > >>> (.htaccess) > >> > >> Probably a bogus httpd config --- overly greedy application of a "don't > >> GET .htaccess" directive. Try files called .ABC > > > > This happens with any hidden file, not just .htaccess files. > > > > Any idea's? > > I agree with Daniel. Check your httpd.conf, and all other conf files it > includes, for directives that restrict hidden files (where by "hidden > files" I am assuming you mean files whose names begin with a "."). > > >
Re: Unable to checkout/add hidden files to repo
This happens with any hidden file, not just .htaccess files. Any idea's? On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote: > Probably a bogus httpd config --- overly greedy application of a "don't > GET .htaccess" directive. Try files called .ABC > > Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500: > > Hello, > > > > I'm having a strange problem and because it has to do with hidden files > I'm > > having a real hard time finding any information about it. everything > > is usually about the .svn folders. > > > > Essentially my repository wont let me check out or commit any hidden > files. > > (.htaccess) >
Unable to checkout/add hidden files to repo
Hello, I'm having a strange problem and because it has to do with hidden files I'm having a real hard time finding any information about it. everything is usually about the .svn folders. Essentially my repository wont let me check out or commit any hidden files. (.htaccess) When i checkout a folder with a hidden file already in it, the hidden files are not downloaded in my working copy. When i do an 'svn ls' the hidden files are shown in the list of files and they also appear in websvn. When i create a new hidden file and try to svn add and commit it i get an error like the following: "svn: '/svn/repo/!svn/wrk/3bc21418-b253-41a7-8d7c-dd2db27c6e5b/path/path/.hidden' path not found" I've never had this issue and i cant find any information on it. This repo has been running with no issues for years now and no changes have been made to it configuration as far as i can tell. The server is running debian lenny with svn 1.5.1 Any help would really be appreciated Thanks, PS: please be sure to CC me on replies, I am not subscribed: jon.gri...@gmail.com Jon Grimes 1340 Home Ave. STE A Akron, OH 44310 Toll Free: 800-493-3450 Fax: 800-446-5906
Directory Already Added Bug?
Hi, I have an issue where by i am trying to merge a directory structure from a into b. One of the changes in that structure is that a directory that is already present in b has been deleted and re-added in a. Hence I am trying to merge in the re-add. The only flagging of this I see is a tree conflict telling it was already added and the ONLY option is 'Keep the local directory' which is unlikely to be the desired actions since one went to the trouble of merging a into b perhaps one might want the 'already added' contents from a? instead of the statusquo of b? Is this correct? -- -- N: Jon Hardcastle E: j...@ehardcastle.com Q: The avalanche has already started. It is too late for the pebbles to vote.
RE: why does my SVN client process die an hour after completion of commit?
Hi Stefan, Philip Thanks for your postings: > On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote: >> So, my question is: is there something in the 'svn commit' protocol >> which causes the client process to do a lot of work, potentially >> causing the client machine to run out of memory, up to one hour after >> the server has determined that a checkin is complete? > > This is a known issue in Subversion 1.6. > Adding many files in one commit uses too much memory, see: > http://subversion.tigris.org/issues/show_bug.cgi?id=1964#desc12 The reason it happens after a commit is complete on the server is that the client has to modify the metadata for all the items in the working copy that were committed. When the commit starts the items being committed all have local modifications of some kind, when the commit is complete they must all be change to unmodified. This can involve a lot of work, writing pristine text and properties, updating the revision numbers. This updating cannot happen until the client knows that the commit was successful. Ah, that makes sense, thanks. So for now I would be best off to regard my 'initial working directory' as suspect, and if I checkout from the server into a new directory, that directory should be correct, yes? (this commit of a large number of files is not something I will have do very often, if at all, after this initial commit). I'm using SVN client v.1.5.4 BTW - a bit older that I expected. I will also look into getting this updated to 1.7. Thanks & Regards Jon N Please consider the environment before printing this email The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender or postmaster (postmas...@hanoverdisplays.com) and delete the material from any computer. Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.
why does my SVN client process die an hour after completion of commit?
Hi all
(This question is a combination of an SVN and a linux question)
I am running andLinux (a linux distribution which co-exists with Windows 7) on
a PC and have a project with a large number (several tens of thousands) of
files which I wanted to put under SVN.
I have an SVN server running over http, created a repo, and performed an
initial commit of the files via an 'in-place commit' process:
cd ~/myproj
svn co http://revisioncontrol/svn/myproj/trunk .
svn add mylargesubdir
time svn ci
This process took a long time (close to seven hours). At the end I got this
prompt on my client console:
. . . . . Killed
(ie. many dots, over a period of hours, as the data was transmitted, followed
by a message that my process had been killed.)
The server log seems to indicate that the commit completed successfully at time
~9:48pm; there are no error messages .
If I look in /var/log/messages on my client machine, I see this:
{{{
Oct 20 21:00:48 andLinux -- MARK --
Oct 20 21:20:48 andLinux -- MARK --
Oct 20 21:40:48 andLinux -- MARK --
Oct 20 22:00:49 andLinux -- MARK --
Oct 20 22:21:09 andLinux -- MARK --
Oct 20 22:41:37 andLinux -- MARK --
Oct 20 22:43:23 andLinux kernel: kded4 invoked oom-killer: gfp_mask=0x201d2,
order=0, oomkilladj=0
Oct 20 22:43:23 andLinux kernel: dd invoked oom-killer: gfp_mask=0x200d2,
order=0, oomkilladj=0
Oct 20 22:43:23 andLinux kernel: [] show_trace_log_lvl+0x1a/0x30
Oct 20 22:43:23 andLinux kernel: [] show_trace+0x12/0x20
Oct 20 22:43:23 andLinux kernel: [] dump_stack+0x15/0x20
Oct 20 22:43:23 andLinux kernel: [] out_of_memory+0x19d/0x200
Oct 20 22:43:23 andLinux kernel: [] __alloc_pages+0x2da/0x330
Oct 20 22:43:23 andLinux kernel: [] read_swap_cache_async+0xa1/0xe0
Oct 20 22:43:23 andLinux kernel: [] swapin_readahead+0x55/0x70
Oct 20 22:43:23 andLinux kernel: [] __handle_mm_fault+0x82e/0xa00
Oct 20 22:43:23 andLinux kernel: [] do_page_fault+0x351/0x690
Oct 20 22:43:23 andLinux kernel: [] error_code+0x6a/0x70
Oct 20 22:43:23 andLinux kernel: [] kmsg_read+0x25/0x50
Oct 20 22:43:23 andLinux kernel: [] vfs_read+0xb5/0x140
Oct 20 22:43:23 andLinux kernel: [] sys_read+0x3d/0x70
Oct 20 22:43:23 andLinux kernel: [] syscall_call+0x7/0xb
Oct 20 22:43:23 andLinux kernel: ===
Oct 20 22:43:23 andLinux kernel: Mem-info:
Oct 20 22:43:23 andLinux kernel: Normal per-cpu:
Oct 20 22:43:23 andLinux kernel: CPU0: Hot: hi: 90, btch: 15 usd: 5
Cold: hi: 30, btch: 7 usd: 6
Oct 20 22:43:23 andLinux kernel: Active:30295 inactive:30529 dirty:0
writeback:0 unstable:0
Oct 20 22:43:23 andLinux kernel: free:509 slab:1850 mapped:42 pagetables:315
bounce:0
Oct 20 22:43:23 andLinux kernel: Normal free:2036kB min:2036kB low:2544kB
high:3052kB active:121180kB inactive:122116kB present:260096kB
pages_scanned:407510 all_unreclaimable? yes
Oct 20 22:43:23 andLinux kernel: lowmem_reserve[]: 0
Oct 20 22:43:23 andLinux kernel: Normal: 11*4kB 3*8kB 1*16kB 1*32kB 0*64kB
1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2036kB
Oct 20 22:43:23 andLinux kernel: Swap cache: add 1043236, delete 1043236, find
25790/146554, race 0+0
Oct 20 22:43:23 andLinux kernel: Free swap = 0kB
Oct 20 22:43:23 andLinux kernel: Total swap = 262120kB
Oct 20 22:43:23 andLinux kernel: Free swap:0kB
Oct 20 22:43:23 andLinux kernel: 65536 pages of RAM
Oct 20 22:43:23 andLinux kernel: 0 pages of HIGHMEM
Oct 20 22:43:23 andLinux kernel: 1542 reserved pages
Oct 20 22:43:23 andLinux kernel: 117 pages shared
Oct 20 22:43:23 andLinux kernel: 0 pages swap cached
Oct 20 22:43:23 andLinux kernel: 0 pages dirty
Oct 20 22:43:23 andLinux kernel: 0 pages writeback
Oct 20 22:43:23 andLinux kernel: 42 pages mapped
Oct 20 22:43:23 andLinux kernel: 1850 pages slab
Oct 20 22:43:23 andLinux kernel: 315 pages pagetables
# etc.
}}}
'oom-killer' is the Linux Out Of Memory killer. So, it looks like the kernel on
my client machine killed the SVN process at around 10:43pm.
Clearly there may be an issue with the memory available on my client machine,
and I need to look into this. But my question is related to the timings
indicated here.
- The server says the process completed successfully at ~9:48pm
- my client svn process was killed at ~10:43pm.
- There were no other tasks running on the client that might have caused
problems AFAIK (I left it on running just the checkin overnight)
So, my question is: is there something in the 'svn commit' protocol which
causes the client process to do a lot of work, potentially causing the client
machine to run out of memory, up to one hour after the server has determined
that a checkin is complete?
If nothing else I'd like to learn a bit more about the svn/http protocol, and
what is going on here. Thanks for any pointers.
jon N
Please consider the environment before printing this email
The informati
Re: Log Entry with no details.
Think you might be on to something there... I'll have to try it out.. then I can sleep easy :) and not think it is corruption! On 7 October 2011 12:55, Neil Bird wrote: > Around about 06/10/11 10:07, Jon Hardcastle typed ... > > I have an oddity I have never seen before. I have a log entry when viewed >> from tortoise that has no author, actions, message and says (no date) for >> the date and time. >> > > I saw that yesterday: for me, it was a permissions thing. > > Under this repo. root were 3 dirs., and I only had read access to one of > them (trunk). Showing a log from the root in Tortoise, I saw an *entry* for > all the revs., but those that pertained to the 2 dirs. I couldn't get at > were blank except for the “(no date)” message. > > -- > [neil@fnx ~]# rm -f .signature > [neil@fnx ~]# ls -l .signature > ls: .signature: No such file or directory > [neil@fnx ~]# exit > > -- -- N: Jon Hardcastle E: j...@ehardcastle.com Q: The avalanche has already started. It is too late for the pebbles to vote.
Log Entry with no details.
Guys, I have an oddity I have never seen before. I have a log entry when viewed from tortoise that has no author, actions, message and says (no date) for the date and time. any ideas? -- -- N: Jon Hardcastle E: j...@ehardcastle.com Q: The avalanche has already started. It is too late for the pebbles to vote. -- -- N: Jon Hardcastle E: j...@ehardcastle.com Q: The avalanche has already started. It is too late for the pebbles to vote.
RE: not storing diffs of binary files
Thanks very much Mark. That thread was very useful and it's great to understand what's actually going on here. I've summarized all this in an answer back on stackoverflow: http://stackoverflow.com/questions/6917505/inexplicable-svn-repository-size-increase-from-small-differences-to-big-files/7001562#7001562 Jon From: Mark Phippard [mailto:markp...@gmail.com] Sent: 09 August 2011 10:50 To: Jon Stafford Cc: Andreas Krey; Daniel Shahaf; users@subversion.apache.org Subject: Re: not storing diffs of binary files On Tue, Aug 9, 2011 at 1:19 PM, Jon Stafford mailto:jon.staff...@complyserve.com>> wrote: Thanks everyone for the responses. To check my understanding, and to give half a conclusion - Every revision apart from the very initial revision of a file is stored as a delta against some previous version. Subversion would typically probably use the least disk space *if* each revision was stored as a delta against the immediately preceding revision. But that would be really slow for reconstructing the 1000th revision. So instead, each revision is stored as a delta against a base of flip-rightmost-1. This generally gives a balance between space used up and time to recreate any given revision of the file. OK, how does all that sound so far? Knowing this I was hoping I'd look again and understand what was going on with my repository with successive zips of my database data checked in. Not quite... I can see that the deltas aren't necessarily against the immediately preceding version - in fact with 15 revisions it's satisfying/reassuring to see them doing exactly as billed in the skip deltas document. The bit I still can't reconcile is the difference in the delta size between xdelta standalone (small) and the delta stored by subversion (large - almost the size of the file itself sometimes). I've checked in various versions of my database data zipped. Some with a month of changes between each revision, some with the most trivial change possible between revisions. For a trivial change: xdelta delta size = 300KB, subversion db\revs file size = 300KB For a month of database edits: xdelta delta size = 3 or 4MB, subversion db\revs file size = 50MB Obviously for fair comparison I'm only picking on revisions where subversion did delta against the immediately preceding revision. So does subversion (version 1.6.11) use an old, not quite so good, xdelta? Or is it just that it applies xdelta after its already done some format manipulation on the file, which then makes it less delta-able? Or something else... I do not understand it enough to give a lot of details so let me point you to an old thread on the list: http://svn.haxx.se/dev/archive-2007-03/1277.shtml The xdelta algorithm has a configurable window that determines the amount of memory used. The more memory you give it, the smaller the delta it can often produce. It is likely the xdelta binary you are using uses a larger window than Subversion. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: not storing diffs of binary files
Thanks everyone for the responses. To check my understanding, and to give half a conclusion - Every revision apart from the very initial revision of a file is stored as a delta against some previous version. Subversion would typically probably use the least disk space *if* each revision was stored as a delta against the immediately preceding revision. But that would be really slow for reconstructing the 1000th revision. So instead, each revision is stored as a delta against a base of flip-rightmost-1. This generally gives a balance between space used up and time to recreate any given revision of the file. OK, how does all that sound so far? Knowing this I was hoping I'd look again and understand what was going on with my repository with successive zips of my database data checked in. Not quite... I can see that the deltas aren't necessarily against the immediately preceding version - in fact with 15 revisions it's satisfying/reassuring to see them doing exactly as billed in the skip deltas document. The bit I still can't reconcile is the difference in the delta size between xdelta standalone (small) and the delta stored by subversion (large - almost the size of the file itself sometimes). I've checked in various versions of my database data zipped. Some with a month of changes between each revision, some with the most trivial change possible between revisions. For a trivial change: xdelta delta size = 300KB, subversion db\revs file size = 300KB For a month of database edits: xdelta delta size = 3 or 4MB, subversion db\revs file size = 50MB Obviously for fair comparison I'm only picking on revisions where subversion did delta against the immediately preceding revision. So does subversion (version 1.6.11) use an old, not quite so good, xdelta? Or is it just that it applies xdelta after its already done some format manipulation on the file, which then makes it less delta-able? Or something else... Jon -Original Message- From: Andreas Krey [mailto:a.k...@gmx.de] Sent: 08 August 2011 13:44 To: Mark Phippard Cc: Daniel Shahaf; Jon Stafford; users@subversion.apache.org Subject: Re: not storing diffs of binary files On Mon, 08 Aug 2011 16:28:42 +, Mark Phippard wrote: ... > All revisions are "deltified" but some are deltified against an empty > stream. I do not know if the diagram is accurate, but revisions 1 and 2 of > the file are both against the empty stream. Revision 0 goes as a regular revision in that diagram, according to the text. This way every rev but the first is deltified; would be stupid otherwise. (And the first is deltified against the empty stream.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
not storing diffs of binary files
I'm trying to understand why subversion isn't just storing diffs of some binary files. It looks like it's taking up more space than it needs to. At length the issue is described here: http://stackoverflow.com/q/6917505/277208 The more summarized version is... I understand that subversion stores files differentially (compressed), even for binary files. And subversion uses Xdelta to help with this. I can do a standalone xdelta on my 50MB zip files: xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file and get a nicely small v1v2_delta.file which is about 3MB. But when I check successive versions of the data.zip into a subversion repository (FSFS, version 1.6.11) I get two ~50MB files in db\revs\0 I appreciate minimizing disk usage isn't the only thing, e.g. performance may be more important. Being able to configure this would be useful in my situation. I've spent a long time trying to figure out what is going on and not got very far. I guess this behaviour is probably deliberate - it would be really interesting to have an idea of different factors deciding subversion behaving in this way. Thanks Jon
Tree conflict: Add/Add on directory
Hi,
I'm having trouble resolving a tree conflict.
I'm working on a feature branch, and I regularly merge from trunk to the
branch. In my latest merge, I got a tree conflict because a directory
("playback") has been added both to trunk and to my branch, with
different contents. I want to get rid of my version and use the one
from trunk.
This should be trivial, but it isn't:
$ svn resolve --accept theirs-full playback
svn: warning: Tree conflicts can only be resolved to 'working' state;
'playback' not resolved
So I thought I'd delete the directory and use "svn cp" to copy the
branch version into my working copy. The delete worked:
$ svn st --depth=empty playback
D C playback
> local add, incoming add upon merge
And I can easily get the URL I need to copy from:
$ svn info playback
URL: http://svnserver/repos/branches/feature/wherever/playback
...
Tree conflict: local add, incoming add upon merge
Source left: (dir)
http://svnserver/repos/trunk/wherever/playback@2373
Source right: (dir)
http://svnserver/repos/trunk/wherever/playback@3515
But the copy doesn't work:
$ svn cp http://svnserver/repos/trunk/wherever/playback@3515 .
svn: Path 'playback' already exists
(I also tried "svn cp
http://svnserver/repos/trunk/wherever/playback@3515 playback", but that
put it in the wrong place (playback/playback/ rather than just
playback/) and seemed to get my working copy in a bugged state,
requiring non-SVN "rm" and "svn cleanup" to get it working again).
I guess I could split the commit into two - if I did a first commit for
the rest of the merge and to delete the "playback" directory, I'd
probably be able to use "svn cp" and do a second commit to re-add it
with the right contents. This seems like a very ugly hack.
Any ideas how to resolve this properly?
Kind regards,
Jon
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
svn revert causes file modification times to go backward
I noticed that after an SVN revert, the files I reverted didn't seem to be getting rebuilt. To my surprise, the modify time following the revert went backwards rather than forwards. Even more confusing, the change time went forward as expected. Following a "touch", everything is copacetic and make successfully rebuilds the file. $ stat foo.c File: `foo.c' Size: 107262 Blocks: 224IO Block: 4096 regular file Device: 811h/2065d Inode: 3563541 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 2354/ jbauman) Gid: ( 1000/ jbauman) Access: 2010-11-03 15:21:56.0 -0700 Modify: 2010-11-03 15:21:38.0 -0700 Change: 2010-11-03 15:21:38.0 -0700 $ svn revert foo.c; stat foo.c; touch foo.c; stat foo.c Reverted 'foo.c' File: `foo.c' Size: 107255 Blocks: 224IO Block: 4096 regular file Device: 811h/2065d Inode: 3563542 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 2354/ jbauman) Gid: ( 1000/ jbauman) Access: 2010-11-03 15:22:40.0 -0700 Modify: 2010-11-02 14:53:49.0 -0700 Change: 2010-11-03 15:22:40.0 -0700 File: `foo.c' Size: 107255 Blocks: 224IO Block: 4096 regular file Device: 811h/2065d Inode: 3563542 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 2354/ jbauman) Gid: ( 1000/ jbauman) Access: 2010-11-03 15:22:41.0 -0700 Modify: 2010-11-03 15:22:41.0 -0700 Change: 2010-11-03 15:22:41.0 -0700 $ svn --version svn, version 1.5.5 (r34862) compiled Jan 8 2009, 05:34:48
RE: Revisions not in chronological order
Giulio Troccoli wrote: >> From: Chris Evans [mailto:chris.ev...@gresearch.co.uk] >> My repository is made up of a load of folder loaded from >> cvs2svn dumps. >> These were loaded individually and have overlapping date ranges. >> When doing an "svn load" it looks like SVN assigns each >> commit to the next revision, regardless of the date the >> commit occurred. >> >> As a result the rage of revisions created for each of the >> loads have overlapping dates and the revisions of the >> repository are not chronological. > >This is expected behaviour if have loaded two or more dumps into the same repository. > >I seem to remember there is a tool out there to merge dumps >file, but I don't remember the name. I don't even know if >it would merge them in chronological order or not. Google >it and see what you can find. http://svn.borg.ch/svndumptool/ Haven't tried it myself, but it claims to do what you want. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SVN Keywords...
http://subversion.apache.org/faq.html#version-value-in-source Kind regards, Jon -Original Message- From: BRM [mailto:bm_witn...@yahoo.com] Sent: 26 October 2010 20:56 To: SubVersion Users Subject: SVN Keywords... I have a series of projects that operate as service daemons; all the projects have a simple main.cpp that loads another class that does the actual work. So I never have to touch main.cpp except when I go to make a release, and then only to update a couple things: version numbers and dates. I'd like to try to automate the data modifications a little bit more; and while SVN has the $Date$ keyword, aka $LastChangedDate$; that's not quite correct for what I want to do - svn after, all svn won't detect a change if there are no actual modifications on the file (e.g. "touch somefile.cpp" won't result in a delta in svn), at least as explained in the svn red book[1]. Would it be possible to have a $LastCommitDate$, and perhaps a $LastCommitRevision$ that is not file specific but name space specific, since SVN operates on name spaces (e.g. ^/some/svn/path) instead of files ( ^/some/svn/path/some.file.with.extension)? Or perhaps $LastUrlCommit...$. In either case the specified name space should likely be the URL/namespace where the file is located, perhaps with an option to have the base URL when it was checked out/exported. This could be provided using arrays, for example $LastCommitDate[0]$ could be the base URL while $LastCommitDate[1]$ is the URL of the file. For the svn:externals use-case, the URL would be related to the external, not to the project pulling the URL in. So suppose the following: Project located at /myproject/trunk, pulls in an svn:external from /myotherproject/tags as lib1; the proposed keyword set would apply to /myproject/trunk only for files that actually exist in the repository under that URL, while the proposed keywords for the files checked out/exported to lib1, which are located under /myotherproject/tags, would apply the URL of the external - /myotherproject/tags and not /myproject/trunk. While I understand the logic present in the $GlobaRevision$ section on in the SVN Redbook[1], there is also some problems with the suggested resolution when trying to do the same thing on multiple platforms, namely and especially MS Windows where processing of 'svnversion' output is impossible with standard tools on the platform to say the least. Ben [1]http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.key words.html __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Path based authorization
Hi, Robert Johnson wrote: > I'm not sure this is a bug or the documentation is wrong, > or I'm misunderstanding the concept. > > In the SVN doc: > > Section 6.5 Path-Based Authorization > > [paint:/projects/paint] > > jane = r > > @paint-developers = rw > > > > Another important fact is that the first matching rule > > is the one which gets applied to a user. In the prior > > example, even though Jane is a member of the paint-developers > > group (which has read/write access), the jane = r rule > > will be discovered and matched before the group rule, > > thus denying Jane write access. Older versions of the SVN book were wrong. The latest version has corrected this. See: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h tml Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How do I enforce a minimum client version when hosted via httpd
Hi, Stephen Connolly wrote: > I remember reading before about a hack/trick that allows you > to ensure that the client is at least mergeinfo aware when the > repository is served via Apache httpd. You can have a start-commit hook. It can reject commits from clients that don't have the "mergeinfo" capability. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html > A better trick would allow blocking clients less than 1.6.13 from connecting ;-) Subversion sends it's version in the User-Agent string. You can test that in your Apache config file. (But this is probably a bad idea unless it's an internal SVN server that's locked down by corporate policy). http://httpd.apache.org/docs/2.2/howto/access.html#env Bear in mind that some people may not be using the official Subversion client. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
svn:externals and http basic auth
I have an external dependency, and the 3rd party repository uses HTTP basic authentication. I tried setting my svn:externals property to use the standard http://user:p...@server.com/path format, but I am still prompted to authenticate at the terminal. Is there a way to get svn to use the user:pass credentials?
RE: Fwd: Repository Directory Tree
Stefan Sperling wrote: > On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: > > I send this email out about once a month or so in what is > > becoming the vain hope I'll get a response... > > > > My subversion repository is in /var/svn. Somehow (and, yes, I'm > > new; I'm evaluating it), I've wound up with the following > > directory structure in my subversion repository: > > > > /var/svn/ > > var/svn/proj1 > > var/svn/proj2 > > var/svn/proj3. > > [snip] > > > > I've tried to do an svnadmin dump and load with --parent-dir, and > > that didn't work. This was the command line sequence after I had > > made a copy of the repository in /var/svn.sav: > > > > svnadmin dump /var/svn.sav> old_repos > > rm -r/var/svn/* > > svnadmin create /var/svn > > svnadmin load --parent-dir / /var/svn< old_repos > > > > But, even though I had parent-dir as / (to try to eliminate one > > of the /var/svn's), I still got /var/svn/var/svn/projects. > > > > What is the way to do this? > > You want to remove the leading /var/svn components from all paths > in the dump file. See here: > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html > #svn.reposadmin.maint.filtering > The part that starts with: > "At this point, you have to make a decision. > Each of your dump files will create a valid repository, but will > preserve the paths exactly as they were in the original repository." > is the interesting part you should read especially carefully. > > Stefan I'm wondering if svndumptool could do this automatically. (Maybe 'svndumptool merge -o out.dump -i in.dump -r var/svn/proj1 proj1' ?) But I haven't tried it. See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is this a bug ?
Hans wrote: > I got no reaction on freenode#svn, so here goes : > > This looks like a bug in 1.6.12 to me : > for a subdirectory with its .svn/ removed > a 'svn up --force .' in its parent does not recreate it > where 'svn up --force dirname' does That won't happen in Subversion 1.7, so I wouldn't worry about it. (Subversion 1.7 won't have .svn folders in subdirectories, so you won't be able to delete them). Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is 'svn lock' possible for replication?
Hi, Steven Woody wrote: > On 20 August 2010 23:19, Steven Woody wrote: > > Hi, > > > > With a replication/write-through setup, can a user execute 'svn lock' > > on master/slaver nodes? Thanks. > > Hey folks, no one can gives me a hint? The SVN Book answers your question. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
Daniel Shahaf wrote: > Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 15:27:25 -0500: > > Ramkumar: > > > Again, I expect that access control/ security is automatically taken care > > > of in the RA layer. `svnrdump load` is just like a user making some changes > > > and committing them one by one except the author and timestamp in the > > > dumpfile are preserved. Why would you want to block this? > > > > A client performing a regular commit cannot currently spoof the author and timestamp, or can they? > > > > Yes: > > svn propset --revprop svn:author > svn propset --revprop svn:date > But not by default. Changing revprops has to be explicitly enabled by the repository administrator. To do this, the server admin has to explicitly create a "pre-revprop-change" hook, and set it to allow the changes. Many "pre-revprop-change" scripts will disallow changes to "svn:date" and "svn:author", although they might allow other revprops such as "svn:log" to be edited. http://svnbook.red-bean.com/nightly/en/svn.ref.reposhooks.pre-revprop-ch ange.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Steven Woody wrote: > Thanks everyone, and, can I get know if the replication/write-through > things support https? Yes, they do. > The master that I want to mirror is using https On the mirror, you need the appropriate Apache modules and configuration. Make sure you have mod_proxy and mod_ssl loaded as well as the normal Subversion modules. The proxy-specific config I've used is: ... SSLProxyEngine on SSLProxyCACertificateFile /some/local/path/master_cert.pem SSLProxyVerify require SSLProxyVerifyDepth 10 ... standard SVN config omitted ... SVNMasterURI https://masterserver.mysite.example/svn The path /some/local/path/master_cert.pem should contain the SSL certificate for your master SVN server. To create it, I just browsed to the master SVN server using a web browser and saved the SSL certificate to a file. (In Firefox: Navigate to SSL page, click padlock in bottom-right corner of browser, "View Certificate", "Details", "Export"). Useful reference: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Ulrich Eckhardt wrote: > On Wednesday 11 August 2010, Ryan Schmidt wrote: > > you can set up a write-through proxy so that people who check out > > from a slave and try to commit will be transparently redirected to > > the master. > > How? It's described in the book: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.s erverconfig.httpd.extra.writethruproxy Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Migrating from 32 to 64 bit
Hi, SVN decides if two repositories are "the same" by comparing their UUIDs. You can get the Repository UUID from the old repository with "svn info", and set it on the new repository with "svnadmin setuuid". Kind regards, Jon From: Leszek Szarlej [mailto:leszek.szar...@gmail.com] Sent: 11 August 2010 18:56 To: Edward Ned Harvey; Leszek Szarlej; users@subversion.apache.org Subject: Re: Migrating from 32 to 64 bit Thank you for your answers. Currently I've setup svnsync and I am doing test run of synchronizing repositories. I will have a small window to migrate repositories. Using the svnsync gives me possibility to do major job before the change window and then final sync during the change. In this step I have some doubts whether users will have possibility to relocate their local copies to new repository on new server. The first step of sync procedure is to create fresh repository, I am afraid that it will have different ID and svn will say "its not the same repository" I will test it but you are welcome to give me your comments. I have about 400 repositories to migrate. Svnsync showed about 60 -70 hours to sync all repos. Thanks much Leszek Szarlej On 11 August 2010 15:50, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 09:11:29AM -0400, Edward Ned Harvey wrote: > As far as subversion is concerned, as long as you get it installed, there is > nothing for you to think or care about. It depends on the Subversion repository backend. If the BerkeleyDB backend is used, a dump/load cycle is probably necessery, so just do it to be on the safe side. With repositories using FSFS, there is nothing to worry about. The file "db/fs-type" in a repository tells you which kind of backend the repository is using: "bdb" or "fsfs" Stefan __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Merging repositories - is it possible?
Hi, Les Mikesell wrote: > On 8/6/2010 10:12 AM, Itamar O wrote: > > On Fri, Aug 6, 2010 at 4:56 PM, JWalker > > This is my first post here. > > > > > > Is it possible to merge several repositories in a new empty > > > repository? > > > > > > I am asking this, because I made several repositories of one project, > > > one repository for mechanics, another for the software, another one > > > for the electronics and so on. Now I see that this will be a bit > > > hardly to maintain when more projects appear in the future. > > > > > > My goal is to create this layout (example) > > > / > > > /mechanics > > > /software > > > /electronics > > > > > > and then load the repository of mechanics to /mechanics, the > > > repository of software to /software and so on. > > > > > > So, is this scenario possible - by bump/load procedure or something > > > else? > > > > This is exactly the use case described in the SVN redbook: > > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html > > #svn.reposadmin.maint.migrate > > But note that although the revision histories are maintained, when you > combine them the revisions will be renumbered and you also won't be able > to specify date ranges because the changes will be out of order in the > combined repository. If you care about that, you could try "svndumptool merge". See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Subversion 1.6 write-through proxy mirroring
Jim Lord wrote: > I'm setting up a write-through proxy mirror. I can run: > > svnsync init --source-username svnsystem --source-password $pass > --sync-username svnsystem --sync-password $pass > file:///data/svn/vtest > https://versiontest2.divxnetworks.com/svn/vtest > from the slave machine versiontest1 > BUT, I can't run: > svnsync init --source-username svnsystem --source-password $pass > --sync-username svnsystem --sync-password $pass > https://versiontest1.divxnetworks.com/svn/vtest > file:///data/svn > on the master without getting the error: > svnsync: DAV request failed; it's possible that the repository's > pre-revprop-change hook either failed or is non-existent > > The pre-revprop-change hooks exist on both master and slave for > the vtest repository What are the filesystem permissions on your pre-revprop-change hook in the target repository? What user does Apache run as? Does that user have execute permission on the hook script? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Debian svn + apache2 configuration errors
Hi, kevin fauchon [mailto:kevin.fauc...@gmail.com] wrote: > AuthzSVNAccessFile /DATA/svn/config [...] > /DATA/svn/conf: > [/] > * = > anonymous = r You need $anonymous here - you're missing the $. So you granted read access to a user that's logged in with the username "anonymous", not to anonymous users. (But I'm not sure why you don't just do "*=r" - any of your users could get read access by simply logging out). > [test:/] > test = rw [...] > And when i try to go to http://svn.monpoulpe.com/test > i have a 403 forbiedden error On a related point... I have a Python script that does "lint" like checks on Subversion AuthZ files. It would have detected this bug, since it reads the ".htpasswd" file and would have reported that you're granting permissions to a non-existant user. Would the Subversion developers be interested in including it in Subversion? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: can't build with zlib
Hi, Edward Ned Harvey wrote: > I have tried everything I can think of, and I can't seem to get > svn to build with the zlib that comes with it. It's always > linking against /usr/lib64/zlib. > After build: > ldd `which svn` | grep libz > libz.so.1 => /usr/lib64/libz.so.1 (0x0034a690) What's the full output of ldd? Are you linking against some other library that's linked against your system zlib? Run ldd on every other library that's listed, to see if any depend on libz.so. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How to allow anonymous access, but not everyone access in path-based authorization?
Hi, Didier Trosset wrote: > I have a subversion server running with apache. It authenticates > users using LDAP configuration and uses SVN path-based > authorizations to limit user access to certain repositories. > This works perfectly. > > Now, I have a service I want to setup (rietveld, for code reviews) > that needs to have an anonymous access to the repository. > [... snip ...] > This did not work until I add an additional line "* = r" in the > authorization file to allow read access to all users. > > For instance, before I add the authorization from a specific IP, > all users were authenticated, and thus had a name. Now, some > accesses are done without a user name! I found the |"-|" user > name in the apache log files, but the line "|- = r"| does not work, > neither do |"anonymous = r"|. I'd like not to allow read access to > everyone in SVN authorization. How can I do this? Subversion's authz files support "$anonymous" to refer to anonymous users. (And "$authenticated" to refer to authenticated users). Kind regards, Jon -- Please direct all replies to the mailing list ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: JavaHL - when using peg makes the difference in diffSummarize()
Hi, "m g" wrote: > Subject: JavaHL - when using peg makes the difference in diffSummarize() > > can you provide me at least one case in which passing > a non-null peg revision to SVNClientInterface.diffSummarize() > returns a different result than when passing null ? > > Thanks > Mário Have you read the SVN book? http://svnbook.red-bean.com/ It has a good explanation of peg revisions. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: cannot break lock due to no matching lock-token
Hi, > could I use a local command line client (while > keeping Tortoise resident) to execute this? Yes. The command line client can be downloaded from here: http://subversion.apache.org/packages.html#windows I use the SlikSVN one, but it really doesn't matter which one you use. Kind regards, Jon -- Please direct all replies to the mailing list. -Original Message- From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:47 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Thanks for replying. I am using TortoiseSVN, which directs me to this mailing list for discussion. Pardon my amateurishness, could I use a local command line client (while keeping Tortoise resident) to execute this? -Original Message----- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, April 14, 2010 7:23 AM To: Tom Jones; users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use "svn unlock --force". See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because "cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog" appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ *** The information in this e-mail is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this e-mail in error please notify the sender by return e-mail delete this e-mail and refrain from any disclosure or action based on the information. *** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, F
RE: cannot break lock due to no matching lock-token
Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use "svn unlock --force". See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because "cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog" appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Version tags in source
Is there a way to imbed the version into the source? For example if I have shell scripts under subversion that are utilized in a released directory (not subversion working directory) - How would I know what version is being used? jon madsen
RE: Can I not use svnadmin load with a remote repository?
Andy Levy wrote: > David Bartmess wrote: > > My company has done a preliminary spec for moving from CVS to > > Subversion, using the python script cvs2svn. The cvs2svn script > > works fine, but when I try to do an svnadmin load of the dump > > file created, using the Assembla https URL, it complains that > > it can't find a "format" file. > > > > After quite a bit of web searching, I think I see the problem. > > The path for the destination of where to load the dumpfile > > contents seems to have to be a file path, not a URL. Is this > > right? Or am I missing something? > > svnadmin requires local filesystem access for everything it does. Yep. Your SVN host (Assembla) might be able to take your dump file and load it for you - try asking them or filing a support request. If they won't do that, then you can work around this by: 1) Create a new empty repository on your hard disk. 2) Use svnadmin load to load the dump file into your local repository. (Note: cvs2svn has the option to create a new repository for you, which would let you skip steps 1 and 2). 3) Use "svnsync" to sync from your local repository to the real one. Note that the target repository has to be completely empty to do this. 4) Delete your temporary local repository. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Multiple Lines for groups in authz conf file
Hi, > I'm using mod_authz to specify permissions in svn. Is there a way > to list the group members on multiple lines instead of just a > single line? For example, instead of: > > [groups] > developers=joe, frank, bob > > I would like to have something like: > > [groups] > developers= > joe, > frank, > bob > > Will this work? The reason is that one of the groups is very > large, and it's messy to have all the users on one line. In Subversion's configuration files, leading whitespace indicates a continuation line. So you could do: [groups] developers = joe, frank, bob Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: svn copy not updating Last Changed Rev
On Mon, Mar 29, 2010 at 18:15:19 -0400, Bob Archer wrote: > You don't show what your pwd is when you do these commands. but I think the > default range is 1:BASE if you are in a working copy. Does the log change if > you use: > > svn log -r HEAD :///tmp/svn-repo/branches/mine/fil > Good question, I was using the repository URLs just to be sure of cases like this, but apparently that isn't enough. I have gone back and confirmed that this occurs even when I'm outside of a working copy. In fact, it occured to me that this should be visible on any public subversion repository that used a server side svn copy operation. Even the repository of svn itself: Here is the most recent log entry for the build subdirectory of subversion in the 1.6.9 tag: svn log --stop-on-copy http://svn.apache.org/repos/asf/subversion/tags/1.6.9/build r901401 | hwright | 2010-01-20 17:08:30 -0500 (Wed, 20 Jan 2010) | 1 line Tag 1.6.9 release with svn_version.h matching tarball. But if you request svn info on the same URL it shows a different revision as the most recent change: $ svn info http://svn.apache.org/repos/asf/subversion/tags/1.6.9/build | grep ^Last Last Changed Author: hwright Last Changed Rev: 884204 Last Changed Date: 2009-11-25 12:23:50 -0500 (Wed, 25 Nov 2009) -- Jon "lib64 is a wart on history and should never have been there." -Tollef Fog Heen
Re: svn copy not updating Last Changed Rev
On Mon, Mar 29, 2010 at 23:53:43 +0300, Daniel Shahaf wrote: > [[[ > % svn up > At revision 1. > > % svnversion > 1 > > % svn cp -q iota iota2 > > % svn ci -q -m "r2: add iota2" > > % svn cp -q ^/trunk/iota ^/trunk/iota3 -m "r3: add iota3" > > % svn up -q > > % svn info iota2 iota3 | grep "Last Changed Rev" > Last Changed Rev: 2 > Last Changed Rev: 3 > Try it with a directory that includes files and subdirectories and you'll be able to reproduce it. The actual directory used as the root of the copy operation has the correct Last Changed Rev, as I noted already: > SVN info on the root of the copy shows the expected information: > > $ svn info file:///tmp/svn-repo/branches/mine > Last Changed Author: jadevree > Last Changed Rev: 5 > Last Changed Date: 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) It is the files and subdirectories of this that are wrong: > But SVN info on the file that got copied with the branch is wrong: > > $ svn info file:///tmp/svn-repo/branches/mine/file > Last Changed Author: jadevree > Last Changed Rev: 2 > Last Changed Date: 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) And this is inconsistent with what svn log reports as the last change: > $ svn log file:///tmp/svn-repo/branches/mine/file > > r5 | jadevree | 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) | 1 line > > test branch > > r2 | jadevree | 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) | 1 line > > foo > -- Jon "lib64 is a wart on history and should never have been there." -Tollef Fog Heen
Re: svn copy not updating Last Changed Rev
On Mon, Mar 29, 2010 at 14:02:06 -0400, Bob Archer wrote: > Why would you expect the last changed rev of a file to change just > because you coppied it to another path? You didn't actually change > that file right? First, the value changes if you use svn copy locally and commit the results. So I would expect the behavior of using svn copy using two URLs to have the same behavior. Second, the revision shows up in the log for that file. So there is an inconsistency here. Either the file was changed and the log is correct, or nothing changed and the log shouldn't really be there either. Finally, you could just as easily argue that branches/mine/ is a copy of trunk/ and did not actually change either. So why would that have an updated revision number but nothing else does? I should add that I only showed this on a file, but it actually happens to both files and directories beneath the root of the copy operation. -- Jon "lib64 is a wart on history and should never have been there." -Tollef Fog Heen
svn copy not updating Last Changed Rev
I noticed that when you svn copy a directory (like for branching and tagging) the 'Last Changed Rev' in svn info only moves forward on the root of the copy and not every file. The most recent revision in svn log will show up as the copy revision though. Shouldn't the 'Last Changed Rev' on a path always be the same as the most recent revision shown in svn log for the same path? I noticed this on svn 1.4.2, but it shows up in 1.6.9 as well. Here is an example from svn 1.6.9 operating with a local repository, but I originally noticed this on svn 1.4.2 with the svn+ssh protocol. $ svn copy -m "test branch" file:///tmp/svn-repo/trunk file:///tmp/svn-repo/branches/mine Committed revision 5. SVN info on the root of the copy shows the expected information: $ svn info file:///tmp/svn-repo/branches/mine Path: mine URL: file:///tmp/svn-repo/branches/mine Repository Root: file:///tmp/svn-repo Repository UUID: f5a3ca28-02f1-438b-b454-8e94791581c1 Revision: 5 Node Kind: directory Last Changed Author: jadevree Last Changed Rev: 5 Last Changed Date: 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) But SVN info on the file that got copied with the branch is wrong: $ svn info file:///tmp/svn-repo/branches/mine/file Path: file Name: file URL: file:///tmp/svn-repo/branches/mine/file Repository Root: file:///tmp/svn-repo Repository UUID: f5a3ca28-02f1-438b-b454-8e94791581c1 Revision: 5 Node Kind: file Last Changed Author: jadevree Last Changed Rev: 2 Last Changed Date: 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) SVN log shows revision 5 as the most recent: $ svn log file:///tmp/svn-repo/branches/mine/file r5 | jadevree | 2010-03-29 13:43:06 -0400 (Mon, 29 Mar 2010) | 1 line test branch r2 | jadevree | 2010-03-29 13:40:30 -0400 (Mon, 29 Mar 2010) | 1 line foo Interestingly enough, this doesn't happen if you do a local copy + commit instead of a server side copy. Having peeked at the fsfs revision files, it seems the two types of copies are represented quite a bit differently internally. $ svn copy trunk branches/bar A branches/bar $ svn commit -m "bar" Adding branches/bar Adding branches/bar/file Committed revision 3. $ svn info file:///tmp/svn-repo/branches/bar/file Path: file Name: file URL: file:///tmp/svn-repo/branches/bar/file Repository Root: file:///tmp/svn-repo Repository UUID: f5a3ca28-02f1-438b-b454-8e94791581c1 Revision: 3 Node Kind: file Last Changed Author: jadevree Last Changed Rev: 3 Last Changed Date: 2010-03-29 13:40:53 -0400 (Mon, 29 Mar 2010) -- Jon "lib64 is a wart on history and should never have been there." -Tollef Fog Heen
RE: merging repositories
Hi,
Tobias wrote:
> I have a project with two different repositories,
> that I want to merge into one common repository.
Would "svndumptool merge" do what you want?
http://svn.borg.ch/svndumptool/
(I haven't tried it, it's just something I found and
bookmarked when investigating Subversion)
> The simplest way would surely be to say:
> $ svnadmin dump Base/ base.dmp
> $ svnadmin dump Develop/ develop.dmp
> $ svnadmin load --parent-dir "Base/" Merged/ < base.dmp
> $ svnadmin load --parent-dir "Develop/" Merged/ < develop.dmp
> However, this does not semantically respect the correct time order
>[...]
> Will "svnadmin load" keep the commit dates
Yes. They're just a revision property.
> and if so, what would be the outcome of, say,
> "svn update -r {someDate}"?)
Undefined (and unpredictable). My understanding is that this
does a binary search, which will go haywire if your dates
aren't monotonically increasing. So you can't use it on
such repositories.
Kind regards,
Jon
--
(Please direct all replies to the mailing list)
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: SVN respository expiry date
Hi, Arthur Chan wrote: > I am requesting SVN checkin time from my previous company. ... > However, they told me that SVN only store logs for 3 months > by default so that all my commit time were lost. There are 2 different places you can get "commit time" information. First, there are the logs from Subversion. These are reliable (no-one apart from the system administrator could forge them). They are optional - you don't have to generate them. If you do generate them, then it's up to you to decide how long to store them for. They can log all activity, including commits, checkouts, and updates. I suspect the logs are what your company is talking about, and it's quite plausible for them to be stored for only 3 months. Secondly, there is the "svn:date" revision property in the repository. These may or may not be reliable, depending on whether your repository has a "pre-revprop-change" hook that allows them to be changed. (By default, they cannot be forged by anyone other than the system administrator. But if your system administrator installs a "pre-revprop-change" hook that allows it, then any committer can change them to any value, without leaving an audit trail). They are generated automatically by Subversion, you can't (easily) turn them off. Subversion will store them forever (or until someone changes or deletes them). These only tell you the commit time, they won't tell you about checkouts or updates. Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: 403 Forbidden in response to COPY request
Hi, Anton Prowse wrote: [...] > [/trunk/specialfile] > user2 = [...] > when I authenticate as user2 I receive the following error > when trying to create a branch from the trunk of "repos1": > Server sent unexpected return value (403 Forbidden) in > response to COPY request for '/repos/repos1/!svn/bc/999/trunk' user2 is trying to copy /trunk/specialfile to somewhere where he'd be able to read it. So Subversion blocks it. In order to create a branch from trunk, you need read access to trunk and every file inside it. Perhaps /trunk/specialfile can be moved somewhere else, so you can remove this restrictive permission? (This may require you to dump the repository and use "svndumpfilter" to get rid of the historical revisions of /trunk/specialfile). Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: "svn log" via svnserve is letting me see things it shouldn't, but "svn ls" works as I expect
Hi, Stefan Sperling wrote: > On Wed, Mar 03, 2010 at 03:01:22PM -0600, Reid Priedhorsky wrote: > > In particular, log messages to files not in > > /cyclingproject/public should not be available. > > Log message are not per file. They are per revision. > They aren't tied to any particular path. > Off-hand I cannot think of a way to prevent them from being seen. But the documentation for how authz works says: http://svn.apache.org/viewvc/subversion/trunk/notes/authz_policy.txt?ann otate=859714 > == > WHAT USERS SHOULD EXPECT FROM PATH-BASED AUTHZ > == > [...] > 2. LOG MESSAGES > > Log information may be restricted, based on readability of > changed-paths. > > * If the target of 'svn log' wanders into unreadable territory, > then log output will simply stop at the last readable revision. > If the log is tracing backwards through time, as the plain > "svn log" command does, the target will appear to be added > (without history) in that revision. > > * If a revision returned by 'svn log' contains a mixture of > readable/unreadable changed-paths, then the log message is > suppressed, along with the unreadable changed-paths. Only > the revision number, author, date, and readable paths are > displayed. > > * If a revision returned by 'svn log' contains only unreadable > changed-paths, then only the revision number is displayed. Is this documentation wrong? Or doesn't it apply for some reason? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org
Hi, Pete Hatton wrote: > Anyone know the unsubscribe information for the old list? I don't know the "official" procedure, but here's what I did: 1) Go to http://subversion.tigris.org/ 2) Log in using the Login link at the top right corner of the page. (The login page has a "Forgot your password" link that will allow you to set a new password, if you forgot your old one). 3) Go to the old Users mailing list page. The links seem to have vanished from the Subversion web site, but I fould it via Google: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=1065 4) Click the link that says "My subscription settings" 5) Untick the box that says "Subscribed" and click the "Save Changes" button. 6) If you're also subscribed to the "dev" list, go to this URL: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=462 Then repeat steps 4 and 5. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Where is the latest SVN 1.6.9 binary for stable debian?
Hi, Pat Farrell wrote: > My debian server is running Lenny, the latest and greatest debian. > > The svn version is svn, version 1.5.1 (r32289) > I'd like to be running 1.6.9 > I can't find the .deb files, or better, a good repository to add to my > /etc/apt sources.list. 1.6.4 is available in the backports.org repository: http://www.backports.org/dokuwiki/doku.php?id=instructions http://packages.debian.org/lenny-backports/subversion But they don't have a 1.6.9 package yet. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: file *.a ignored
Hi, Soft [mailto:s...@gmx.ch] wrote: > On Windows we use Tortoise 1.5.9 and Subclipse in Eclipse. [...] > Lets say I move a file to a working copy with the extension *.a. It gets > immediately marked as ignored. [...] > I did remove the comment on the global-ignores line. It didn't help. *.a > files are still marked as ignored. Can you try adding the files using "svn add" on the command-line? If that works, I suggest you ask on the Tortoise and Subclipse mailing lists, as it might be client-specific. Those mailing lists are here: http://tortoisesvn.tigris.org/ds/viewForumSummary.do?dsForumId=4061 http://subclipse.tigris.org/ds/viewForumSummary.do?dsForumId=1047 Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: subversion-1.6.9 build error [reproducible]
Hi, ^M is CR. Given the output of "cat", it looks like the file contained: > > > /* This file is automatically generated from > > > * subversion/libsvn_fs_fs/rep-cache-db.sql > > > * Do not edit it directly, but edit the source file and rerun 'make' > > > */ > > > > > > #define REP_CACHE_DB_SQL \ > > > "^M "\ > > > "pragma auto_vacuum = 1;^M "\ > > > "^M "\ > > > "^M "\ > > > "create table rep_cache (hash text not null primary key,^M "\ > > > "revision integer not null,^M "\ > > > "offset integer not null,^M "\ > > > "size integer not null,^M "\ > > > "expanded_size integer not null);^M "\ > > > "" If the compiler is tolerant of dodgy line breaks*, and accepts a bare CR as a Mac-style line break, then the file is invalid C. This is because it starts: > #define REP_CACHE_DB_SQL \ > " (Note that the #define ends here) > "\ > "pragma auto_vacuum = 1; > "\ etc. This is consistent with the compiler error messages. Does subversion/libsvn_fs_fs/rep-cache-db.sql have Windows style CR-LF line breaks? And does the Python script that reads it assume it has native (UNIX style) line breaks? ... Ok, I've just managed to reproduce this and confirmed my speculation above. Reproduction recipe: On Linux: > > > > 1. Get the source code subversion-1.6.9; Using the ZIP file, not the tar.gz. > > > > 2. Run 'autogensh' without error; > > > > 3. Run 'configure' without error; > > > > 4. Run 'make' with below error: Jiang: The ZIP file is only intended for building on Windows. If you're building on Linux, you should use the TAR.GZ or TAR.BZ2 files. (They are subtly different, and that difference caused the build error). Kind regards, Jon (* Such tolerance is usually a good thing; e.g. if I use Pythonwin to edit a file, it leaves existing UNIX-style line breaks alone but any new line breaks will be Windows style). -Original Message- From: Hyrum K. Wright [mailto:hyrum_wri...@mail.utexas.edu] Sent: 26 January 2010 06:58 To: Jiang Li Cc: users@subversion.apache.org Subject: Re: subversion-1.6.9 build error Glad to hear that you finally got it working. Was the problem the ^M characters? If so, I wonder if it is specific to your platform, or more general. But the entire episode does make me wonder why we require people building to generate these files locally. I'll take a look at the pre-build system and see what I can find out. -Hyrum On Jan 25, 2010, at 5:27 PM, Jiang Li wrote: > Hi Hyrum, > > You are an expert, I am able to compile v1.6.9 successfully. > > Here is my update. > > 1. I tried again by downloading subversion-deps-1.6.9 and compiled again, but with the same problem. > 2. I double check the file subversion/libsvn_fs_fs/rep-cache-db.h with 'vi' editor, I found that there are extra '^M' characters in this file. Using 'cat' will not show this. So this is the problem caused by auto-generation. I removed the extra '^M', then run 'make', it works. > > Thanks again! > Jiang Li > > > > > 2010/1/25 Jiang Li > Hyrum, > > Thanks! Tomorrow I will download Subversion 1.6.9 dependency package for a try. > > I suspect the problem was caused by not using that package. I will update you the result. > > I will go offline now. Thanks again for your help! > > > Jiang Li > > 2010/1/25 Hyrum K. Wright > > On Jan 25, 2010, at 8:55 AM, Jiang Li wrote: > > > Hyrum, > > > > No luck. The file will be re-generated again after running 'make'. > > As it should be. > > > 2010/1/25 Hyrum K. Wright > > Can you try just removing the file and then running 'make' again? > > > > On Jan 25, 2010, at 8:48 AM, Jiang Li wrote: > > > > > Hi Hyrum, > > > > > > Thank you so much for your quick reply! > > > > > > Here is all the content of file subversion/libsvn_fs_fs/rep-cache-db.h. > > > > > > Just for your information, I just downloaded subversion 1.6.6 and I was able to compile this version successfully. I am fine with v1.6.6, but I will try to compile 1.6.9 tomorrow for a last try. This is late in my evening. I appreciate your any suggestion. > > > > > > > > > $ cat rep-cache-db.h > > > /* This file is automatically generated from > > > * subversion/libsvn
RE: sync bug -> corrupted proxy repo
Hi, > I am assuming that if the commits must start at least one > second apart - then the sync from the post-commit hook > would not be able to reach a race condition. > Is this a reasonable assumption? No, the bug is worse than that. Suppose there are 3 commits: - At time 12:00:00, a commit starts sync process #1. The sync takes 6 seconds. - At time 12:00:02, a commit starts sync process #2. This blocks due to sync process #1's lock. - At time 12:00:04, a commit starts sync process #3. This blocks due to sync process #1's lock. - At time 12:00:06, sync process #1 finishes. Sync processes #2 and #3 both try to take the lock; due to the bug they may _both_ succeed in taking the lock. Chaos ensues. I suggest you use the "flock(1)" tool. [1]. This is installed as a standard part of Debian (it's in the util-linux package). Something like this, in your post-commit hook: --- cut here - start --- #!/bin/sh /usr/bin/flock --wait 1200 \ -x /var/lock/svn_sync_lock \ /usr/local/bin/svnsync sync --non-interactive \ http://mirrorserver.example.com/svn & --- cut here - end --- You will need to make the /var/lock/svn_sync_lock file and ensure it's writable by the user your post-commit hook is running as. "flock" is a mature, tested piece of code to handle locking. It will ensure that only one copy of svnsync is running at a time. That way, the race condition in svnsync is avoided. Kind regards, Jon [1] http://www.google.co.uk/search?q=man+flock%281%29 -Original Message- From: Andersen, Krista [mailto:krista.ander...@itg.com] Sent: 15 January 2010 22:29 To: Jon Foster; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug -> corrupted proxy repo Thank you Jon, for your explanation and workaround. Are there any "best practices" that we can advise our dev groups to follow to avoid this problem? Otherwise, your suggestions seem to indicate I would have to run the sync on a cronjob and not with the hook script. That is something we would like to avoid. So I have added a start time comparison and sleep in a start-commit hook instead. Do you see any reason why this would cause other problems? I am assuming that if the commits must start at least one second apart - then the sync from the post-commit hook would not be able to reach a race condition. Is this a reasonable assumption? #!/usr/bin/sh # START-COMMIT HOOK # kanderse Jan 13, 2010 # The start-commit hook is invoked before a Subversion txn is created # in the process of doing a commit. # This script checks the start time and compares with the start time # of the previous commit. It will cause a commit to wait one second if # the last commit was started less than one second earlier. # The purpose of this wait is to prevent known issue 3546 [1][2]. # a race condition involving multiple sync processes running at # the same time that result in a corrupted proxy. REPOS="$1" USER="$2" DATE1=`cat /$REPOS/hooks/start-time.txt` # previous start time DATE2=`/usr/local/bin/date +%s` # record current start time echo $DATE2 > /$REPOS/hooks/start-time.txt # echo $DATE2 $DATE1 `expr $DATE2 - $DATE1` if [ `expr $DATE2 - $DATE1` -lt 1 ] then sleep 1 # to prevent sync race that results in sync duplication and corrupted proxy fi # All checks passed, so allow the commit. exit 0 Krista Andersen Global Development Infrastructure Investment Technology Group, Inc. 400 Corporate Pointe, 8th Floor Culver City, CA 90230 Direct: 213.270.7570 -Original Message- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, January 13, 2010 5:13 AM To: Andersen, Krista; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug -> corrupted proxy repo Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: > Twice I have seen one of my proxy repositories become corrupted due > to an apparent bug in the svnsync sync process. Has anyone else > seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. > Here is a comparison the output of the svn log -v for the offending > revisions (324,325) on both the corrupted and non-corrupted proxy > repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). > I am a bit concerned about the stability of Subversion since this > is the second time in two months that I have had to fix this issue. > Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook s
RE: sync bug -> corrupted proxy repo
Hi, Ryan Schmidt wrote: > But Subversion blocks the commit until the post-commit is done. That particular SVN client will be blocked. But if you have two users committing at the same time, or if a user runs "svn" twice in parallel, then the post-commit hook will be run in parallel. Here's how I tested this. I created a new repository with a post-commit hook that takes 30 seconds to run. I then checked that it works, and that a normal commit took 30 seconds. I then did two commits in parallel, and that took 30 seconds. This shows that the post-commit hook is running in parallel - if it had been run in series, then it would have taken 60 seconds for 2 commits. (I also checked the output of "ps" and observed the two "post-commit" processes running). ~$ mkdir svnscratch ~$ cd svnscratch/ ~/svnscratch$ svn --version | head -n1 svn, version 1.6.8 (dev build) ~/svnscratch$ svnadmin create repo ~/svnscratch$ cat >repo/hooks/post-commit #! /bin/bash sleep 30 ~/svnscratch$ chmod a+x repo/hooks/post-commit ~/svnscratch$ time repo/hooks/post-commit real0m30.004s user0m0.000s sys 0m0.008s ~/svnscratch$ time svn mkdir -m "Test" file://`pwd`/repo/trunk Committed revision 1. real0m30.030s user0m0.008s sys 0m0.008s ~/svnscratch$ time ( svn mkdir -m "Test" file://`pwd`/repo/branches & svn mkdir -m "Test" file://`pwd`/repo/tags ) Committed revision 2. Committed revision 3. real0m30.069s user0m0.004s sys 0m0.020s ~/svnscratch$ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: malformed file problem -- version 1.5.7
Hi, James D. Parra [mailto:jam...@musicreports.com] wrote: > Is there a way that I can repair this? No idea, sorry. But: > Is there a way to roll back to revision 11529 and start there? Try svnadmin dump with the -r parameter to dump just the revisions you want to keep, then svnadmin load to load them into a new repository. Any checkouts of r11529 or earlier should be OK; if you have a later checkout then you'll need to delete it and re-checkout. > Should I remove all the revision number files greater that 11529 Hand-editing the repository sounds like a bad idea*... you might get rid of this corruption but introduce a different corruption. Using dump/load should give you a valid repository. Kind regards, Jon [*] It's number zero on the "Subversion Worst Practices" guide: http://www.red-bean.com/fitz/presentations/2007-07-27-OSCON-svn-worst-pr actices.pdf ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug -> corrupted proxy repo
Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: > Twice I have seen one of my proxy repositories become corrupted due > to an apparent bug in the svnsync sync process. Has anyone else > seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. > Here is a comparison the output of the svn log -v for the offending > revisions (324,325) on both the corrupted and non-corrupted proxy > repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). > I am a bit concerned about the stability of Subversion since this > is the second time in two months that I have had to fix this issue. > Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook scripts to use the lockf or lockfile tools[3] to ensure that only one instance of svnsync runs at once. Kind regards, Jon [1] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127115356.gc9...@jack.stsp.name%3e [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3546 [3] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127132659.ge9...@jack.stsp.name%3e ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: restricting sub-directory permissions
Hi, Gabriel Ricardo wrote: > I cannot figure out how to restrict permissions on a sub-directory. > What I want is to have anonymous read/write access to everything > except a sub-directory, where only two users have read/write and > everyone else has no access (read or write). I've done a lot of This looks relevant: http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html >> Since anonymous users can checkout the tree, Apache never bothers >> to query you for authentication credentials. And you can't force >> Subversion to transmit authentication credentials when Apache >> hasn't asked for them. There are workarounds documented in the blog post. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
