Re: Subversion upgrade from 1.5 to 1.6
Hello, I agree that dump/restore is the best option but in some cases, a repository may be so large that dump/restore is unpratical. The "svnadmin upgrade" command is a minimal operation to do but your repository structure will not be sharded (if it comes from 1.4 for instance). My preference is: - backup with .tar.gz - svnadmin upgrade to enable 1.6 features - my own version fsfs-reshard can reshard/unpack from 1.3 to 1.6 versions (I have post it here few weeks ago with how to) - svnadmin verify That's all and it has not consumed three time disk space and 2 hours of CPU ! The fsfs-reshard script is not necessary but your repository may stay in "linear" mode instead of the more efficient "sharded" mode. This script also helps you tweak the shard size to improve disk-access performance (mostly on windows or over SAN) Kind regards -- Yves Martin
Re: svn 1.3 crashing after sometime
Hello, For an upgrade from 1.3 to 1.6, I have simply apply "svnadmin upgrade" command and check integrity with "svnadmin verify". Then, the repository is still in "linear" mode - which is not an issue, it works. But for performance reason, it is better to move to "sharded" mode. To do so, I have worked on fsfs-reshard.py script. You will find it with documentation how to use it safely here: http://ymartin59.free.fr/wordpress/index.php/tune-subversion-fsfs-repository/ Kind regards - "Nico Kadel-Garcia" a écrit : > On Thu, Jul 1, 2010 at 10:04 PM, west alto > wrote: > > Thanks guys, Ho do i upgrade from 1.3 to 1.6? Do i need to install > > first 1.4 then do a svn dump and load, then 1.5 and then svn dump > and > > load etc. > > No, move aside the repository, do a good backup to tape, then install > version 1.6. Then do an "svnadmin hotcopy" with version 1.6, which > should build you a nice clean upgraded and compatible copy you should > put in place of the old repository. -- Yves Martin
Re: svn 1.3 crashing after sometime
Sorry, page link has changed: http://ymartin59.free.fr/wordpress/index.php/projets/tune-subversion-fsfs-repository/ Comments and feedback are welcome - "Yves Martin" a écrit : > Hello, > > For an upgrade from 1.3 to 1.6, I have simply apply "svnadmin upgrade" > command > and check integrity with "svnadmin verify". > > Then, the repository is still in "linear" mode - which is not an > issue, it works. > But for performance reason, it is better to move to "sharded" mode. > > To do so, I have worked on fsfs-reshard.py script. You will find it > with > documentation how to use it safely here: > http://ymartin59.free.fr/wordpress/index.php/tune-subversion-fsfs-repository/ > > Kind regards -- Yves Martin
Re: svn 1.3 crashing after sometime
Hello, Your repository layout is probably "linear" now. According to the number of revisions, revision sizes and the underlying operating system it may be interesting to switch to "sharded" layout and tune the shard size (default is 1000 revisions): http://ymartin59.free.fr/wordpress/index.php/projets/tune-subversion-fsfs-repository/ A good performance test case is to measure time required by "svnadmin verify" to check your repository. Best regards, - "west alto" a écrit : > Thanks guys, i'm new to upgrade using your way. which is safer using > svnadmin dump/load or svnadmin upgrade/verify or svnadmin hotcopy > given my situation where users can afford downtime. > > Please check if my process is correct: > > - remove svn 1.3 and all its dependencies. > - install svn 1.6 > - backup my repository > - svnadmin upgrade /path/to/repository > - svnadmin verify /path/to/repository > > After the steps above, is my repository now usable for 1.6? any other > steps so i could tweak my repository for best performance? -- Yves Martin
Re: fixing files committed with wrong eol-style
Hello, Without the "svn:eol-style" property any file content is considered as binary. At that point, checkouted files on Windows and Linux have "CR-LF" eol. If you want to run your script on Linux, you should run a "dos2unix" (or equivalent) and add the property "svn:eol-style" on your files before commit. Beware, that is just a guess, I have not tested myself ! On Windows, either use Cygwin for Bash, Perl, Ruby... or the win32 port of your scripting langage. Sure it exists ! By the way, I doubt "diff" is sane in any case... just check a "svn diff" from Linux for instance. The "perfect" fix whould be to dump the repository content, add "svn:eol-style" properties at file addition in dump and the load it into a new repository. OK that is really too heavy... Another advice: you should distribute a correct "autoprops" settings to your dev team to avoid that issue at source Best regards Yves - "Simon Kitching" a écrit : > We’ve got a repository containing a lot of text-files committed from > windows systems without the svn:eol-style=native setting. Some > developers now want to work on these from Linux. > > I would therefore like to fix the eol-style. Writing a script on linux > to find all the relevant files and run “propset svn:eol-style native” > on them is easy enough. However I’ve noticed that if the change is > committed from * linux *, then the commit not only changes the file > properties, but also * every line-ending in the file *, ie looking at > diffs between files before and after this change is now pointless. > Committing exactly the same propset change from *windows* just sets > the property without the whitespace problems; checking out on both > systems then works as expected, and diffs between repository versions > are sane. > > However it’s much more convenient to write and run this script from > linux. Is there any way from linux to persuade subversion to just set > the eol-style property? -- Yves Martin
Re: Supported platforms
Hello, No idea but it sounds complex... for un-expressed needs. What are your real needs ? If you want your own SVN repository in your pocket, I think it is simpler to: - use svn win32 release as "zip" (it is portable) - use protocol "file://" to access your repository on key Best regards Yves - "Phil Johnson" a écrit : > Is there a version of Subversion that will run as a USB portable > application under Xampp ? -- Yves Martin
Re: fixing files committed with wrong eol-style
On Tue, 2010-07-13 at 09:44 -0500, Les Mikesell wrote: > On 7/13/2010 8:57 AM, Geoff Worboys wrote: > > Les Mikesell wrote: > >> There are workarounds but you can't just expect things to > >> work in general and pretend it is normal. And some of > >> those workarounds may involve silently changing to the > >> preferred local line endings - and if anything but subversion > >> itself does that it becomes a change in every line when > >> committed, making diffs useless. > > > > This may be true for some *nix systems/tools. But... > > > > For most modern (Windows) development software it is not a > > matter of "workarounds". They simply process the files and > > accept whatever line endings they find. Good editors will > > automatically switch between CRLF, LF and CR EOL modes > > according to what they find. They don't change the file > > (unless asked) they change their own mode operation. > > > > If your developers all work with LF then there will be no > > confusion and no need for workarounds. If anyone makes a > > mistake and accidently commits a file with CRLF it is an > > easy fix to resolve ... although most Windows software wont > > care even if you don't bother to fix it. > > If you have to worry about mistakes, you are doing workarounds. What > windows editor will create new files with LF endings by default? Never-ending debate/troll... The best option: CR-LF on Windows and LF on Linux and autoprops for everyone ! To illustrate, worst examples I have seen: * Cygwin installed with "LF" text file support to run "cvs" command line. Result: appending a new partial end-of-line at each commit - not fun ! * Unix scripts edited on Windows without eol-style. Result: on Linux, the shebang (#!) is invalid and the interpreter command is invalid: /bin/bash^M not found ! Best regards Yves
Re: Poor performance for large software repositories downloading to CIFS shares
On Tue, 2010-07-13 at 15:57 -0500, Les Mikesell wrote: > On 7/13/2010 2:50 PM, David Brodbeck wrote: > > > > On Jul 13, 2010, at 5:50 AM, Les Mikesell wrote: > > > >> Nico Kadel-Garcia wrote: > >>> I've got some colleagues with a rather large Subversion repository > >>> whose trunk includes over 10,000 files and over 500 Meg of actual > >>> content for various reasons. What we're finding is that checking it > >>> out it on a Windows client to a local hard drive takes perhaps 3 > >>> minutes. Downloading it to a mounted Windows (CIFS) share takes > >>> roughly half an hour. > >> > >> What's the server on the CIFS side? If it is Linux/samba, it may be the > >> overhead of making a case sensitive filesystem look case insensitive > >> (consider what has to happen when you create a new file in a large > >> directory and have to check if the name already exists). > > > > This could be a lot of it if a substantial number of files are in one flat > > subdirectory. CIFS really, really does not deal with large directories > > well. Neither does NFS, but the way Windows handles directories tends to > > make it worse. > > I think CIFS is just the network protocol. The real issue is on the > physical filesystem side. When you open a file for writing, the > underlying system has to determine if that file name already exists and > if not, find or create a new filename slot to create it. And this has to > be done atomically, since other processes might be trying to create the > same file at the same time and only one can succeed. This is bad enough > in a large directory when you let the OS deal with exact matches, but if > you are faking case insensitivity you have to do much more work in user > space to find the potential collisions with everything locked for longer > times. You're right CIFS is just the protocol. And Samba implements it efficiently... Windows Explorer (XP version) often transfers slower that Linux "smbclient" command line (measures on a single large file) And Windows often runs anti-virus ! Nico, let's try with a "smbmount" point on Linux to compare with NFS. I do not understand the option to publish a "ready-to-use" checkout. - authentication information like username may be included in repository URL, so it must be modified in order to commit - such a working copy contents twice its volume To publish a clean state, you should prefer an "export" in that case I have seen 1 Gb working copy properly checkouted on a local disk. When the working copy is there, just use "update" and "switch" to limit transfer and disk writes... Why doing a new checkout each time ? With large working copy checkout, older TortoiseSVN versions have troubles/bugs. You should use latest version available - or native win32 "svn.exe" command line binaries.
Re: fixing files committed with wrong eol-style
- "Geoff Worboys" a écrit : > My apologies if my raising of this was seen as trolling. I > was not attempting too suggest which was the best for all > situations, simply that Nico's solution is viable for many > projects these days. > > Obviously if you are going to continue to use old *nix based > scripts that remain vulnerable after all these years then > of course you must work-around such limitations, for which > the features of svn are very convenient. Well, that is not "limitation" but a de-facto situation. On Unix, a script with CR-LF is really unlikely to work, either with Bash, Perl or others... The same way a .bat script on Windows fails if LF. For me, this SVN feature is not for "work-around" but to support multi-platform development "the right way". http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html And what about text file encoding ?? That is so easy to find two Linux boxes in UTF-8 and latin-1 encodings even in the same company in Europe, it is already a nightmare. We really have to "work-around" non-ANSI-compliant developers languages ! As Subversion does not provide a proper encoding support, developers must be fixed so they do not write comments in non-ANSI characters with their non-US keyboards ;) In fact, I could not wait and I use pre-commit hooks to validate text content compliance with project policy concerning charset/encodings. So the end-of-line problem is really simple compared to encodings. And with developpers all around the world working on the same codebase, it is difficult to check/enforce everyone use the "right tool" with the proper configuration on any platform. -- Yves Martin
Re: Poor performance for large software repositories downloading to CIFS shares
On Tue, 2010-07-13 at 20:40 -0400, Nico Kadel-Garcia wrote: > Well, yes, except that updating an "export" can't be done since it > will lack the rest of the .svn information. The point is that they can > download an up-to-date working copy directly, rather than over the > poor performance of the CIFS share. So why are your users unable to access directly to the Subversion repository either with http(s) or svn protocols ? > > I have seen 1 Gb working copy properly checkouted on a local disk. > > When the working copy is there, just use "update" and "switch" to limit > > transfer and disk writes... Why doing a new checkout each time ? > > And that actually works. There are problems with this approach: this > local disk is inaccessible from other working systems without serious > crossmounting craziness, is not workable for high availability > services, and causes any local modifications that haven't been checked > in to be lost when switching to another system. Do I guess you try to prevent a work-day job loss by such a complex system ? I think it is cheaper and more comfortable to setup RAID-1 disks on workstation... If you want your user to commit to the repository regularly (twice a day for instance even when code does not compile), maybe an option is to make them commit their work in individual branches which are merged when job is over.
Re: Repository shrinkage on conversion 1.5 -> 1.6?
On Wed, 2010-07-28 at 11:44 +0100, John Beranek wrote: > I believe we do have a lot of traditional ttb branching, plus > additionally some copying from "common" directories to project directories. > > Thanks for your quick answer, it reassures me somewhat that data hasn't > gone missing. ;) Hello John, If interested, you can use my procedure and fsfs-reshard script to upgrade from 1.5 to 1.6 without dump/load (really faster) and improve performance/storage with a specific shard size tuning (default is 1000 revisions in a pack): http://ymartin59.free.fr/wordpress/index.php/projets/tune-subversion-fsfs-repository/ Regards Yves
Re: Post commit script examples?
On Thu, 2010-08-19 at 11:24 -0600, Greg Alexander wrote: > Hi Csaba, > Thanks for the response. Yes, I am beginning to have a good feel for > what Subversion was designed for, but I would still like to implement > something. I saw the page in the book you reference, but I cannot find any > examples on how to really implement. Any pointers anyone can provide would > be great! Really Allan has described the right way to do it: - As a first step, create a script to do a checkout, add "svn:needs-lock" property on files you want and do a commit. So it should be OK for existing content. For file additions after that point: - Distribute auto-props "config" file with "svn:needs-lock" property for binary files that cannot be merged as source text As far as I know, that file is the same for all client/platform. On Linux (and probably MacOS X), command line svn and other clients read ~/.subversion/config On Windows, command line svn and TortoiseSVN read Application Data\Subversion\config - Implement a pre-commit hook to reject commit submitting file without "svn:needs-lock" property when it is required The pre-commit hook can even display an URL with documentation and "config" file to install so that property is properly set at addition. By the way, if work on files is not "segmented" enough (by team, by time slice, by modules - think at splitting content in multiple smaller files) locking will not help; Developers cannot afford to wait for lock releases and will find the work-around: branching Then they may tell you to merge their work ! My opinion, there is only one response: education and proper organization. Regards Yves Martin
Issue with svn log --diff option
Hello, I have used "svn log --diff path/to/myfile.txt" but the command generates history from the current working directory instead of limiting the report to the provided path. Is it the expected behavior ? If not please create an issue in tracker. -- Yves Martin
Re: Issue with svn log --diff option
Hello, First, Stefan, thanks for your quick answer. You're right, Subversion 1.7.4 "log --diff" works better. But copy operation support is still limited. Here is a quick description of my repository status: $ svn log resources/favicon.ico r429 | B | 2010-06-15 14:35:13 +0200 (mar, 15 jun 2010) | 1 line r388 | B | 2010-03-05 16:52:29 +0100 (ven, 05 mar 2010) | 2 lines r288 | B | 2009-08-28 11:18:37 +0200 (ven, 28 aoû 2009) | 1 line r98 | A | 2008-02-25 12:17:51 +0100 (lun, 25 fév 2008) | 2 lines The file has been moved from different location with copy operations in revision 288 and then 429. $ svn log --diff resources/favicon.ico - is able to generate the diff for 388-429 move - fails to generate the diff for 98-288 move with the error message: svn: E160013: Diff target 'REPO/resources/favicon.ico' was not found in the repository at revisions '287' and '288' So I would say the diff option is able to pass through one copy operation but not two copy operations. I hope my description is enough to create a test case to confirm/invalidate my hypothesis. Regards, Yves Martin Le 27 mars 2012 19:25, Stefan Sperling a écrit : > If you can reproduce it with 1.7.4, can you please try to provide an > example 'svn log' invocation against a public Subversion repository > (for instance, http://svn.apache.org/repos/asf) that shows the problem?
Trouble with shared object so file with svn_load_dirs.pl
Hello, I try to use svn_load_dirs.pl to update my vendor branch on Linux with svn 1.7.4. I got latest version from http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs Everything seems to be OK, except for one file - a Unix binary .so executable file - the script detects it as added whereas it is already present in the branch working copy and it has not changed at all. As a result, the "svn add" operation just fails with: svn: warning: W150002: '/path/to/current/myFileWithSomeCapLetters.so' is already under version control svn: E29: Could not add all targets because some targets are already versioned svn: E29: Illegal target for the requested operation Press return to quit and clean up svn working directory: I have checked that: - file names are exactly equals, case is correct - files are exactly identical - file properties in the vendor branch To clean the situation, I have removed "svn:eol-style" and "svn:keywords" properties on the existing file in branch but kept "svn:executable". After a new checkout of the branch, the operation still fails. Here is my command svn_load_dirs.pl -v -v -w vendorbranch -t vendorrelease_2 https://hostname/subversion/repository branches/vendorbranch vendorrelease_2 How to diagnose what is wrong ? Thank you in advance for your help -- Yves Martin
Re: Trouble with shared object so file with svn_load_dirs.pl
Le 23 avril 2012 17:46, Yves Martin a écrit : > Everything seems to be OK, except for one file - a Unix binary .so > executable file - the script detects it as added whereas it is already > present in the branch working copy and it has not changed at all. > > As a result, the "svn add" operation just fails with: > svn: warning: W150002: '/path/to/current/myFileWithSomeCapLetters.so' > is already under version control > svn: E29: Could not add all targets because some targets are > already versioned > svn: E29: Illegal target for the requested operation > Press return to quit and clean up svn working directory: > How to diagnose what is wrong ? Hello, I browse the Perl source and discover that the "global ignores" option defaults to the variable from .subversion/config and it contains the "*.so" pattern ! As this ignore list is used when scanning the source / working copy, the file from the "vendor release" is detected as added. What I find strange is why the global ignore list is not used to scan the "vendor release" too. So here is the solution: I have to define manually the "global_ignores" option on command line. -- Yves Martin
svnadmin load issue about "svn:mergeinfo" property
Hello, I am merging multiple repositories with dump/load into a single one and almost everything works well because the node structure in each /trunk does not conflict. To describe the situation: repoA (1999 revisions): /trunk/appA with "svn:mergeinfo" containing "/branches/1.0:1000-1010" and "/branches/featureX:800-820" repoB (600 revisions in dump): /trunk/appB with "svn:mergeinfo" containing "/branches/1.0:500-505" Both contains the same "/branches/2.0". repoA: /branches/2.0 with "svn:mergeinfo" containing "/branches/1.0:1000-1010" and "/branches/featureX:800-820" repoB: /branches/2.0 with "svn:mergeinfo" containing "/branches/1.0:500-505" I am loading a (filtered) dump of "repoB" into a copy of "repoA" and I get the following result: repoMerge (2599 revisions): /branches/2.0 has "svn:mergeinfo" with only "/branches/1.0:2500-2505" I would have expected the "svn:mergeinfo" to contain: /branches/1.0:1000-1010,2500-2505 /branches/featureX:800-820 Am I wrong ? Is there anything I can do to work-around the issue or a patch is required in "svnadmin load" ? Thank you in advance for your help -- Yves Martin
svnrdump produce a strange dump file
Hello, I have a Subversion 1.6.17 server running on Debian Linux and access through HTTPS. I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump of the repository: svnrdump dump -r 51686:77787 https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip > amodule.dump.gz I got a version 3 dump which has the following trouble: almost all files content begins with a strange "SVN" binary sequence. Here is an excerpt of the dump itself for such a file: Node-path: trunk/amodule/pom.xml Node-kind: file Node-action: add Prop-delta: true Prop-content-length: 10 Text-delta: true Text-content-length: 3271 Text-content-md5: 1e6f17c85e486bfec9b0f71291cad435 Content-length: 3281 PROPS-END SVN^@^@^@<99>9^C<99>9<80><99>9http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> As a result, load operation fails as Text-content-md5 cannot be verified. According to documentation svnrdump is compatible with Subversion server 1.4 for dump. What is wrong ? Thank you in advance for your help -- Yves Martin
Re: svnrdump produce a strange dump file
On Thu, 2015-10-01 at 09:29 -0400, Nico Kadel-Garcia wrote: > If you're doing an rsync or scp to a remote system and doing the > svndump there, you're running the risk of transferring content in the > middle of an atomic operation and thus confusing the system. > > > svnrdump dump -r 51686:77787 > > https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip > > > amodule.dump.gz > Does anyone actually use "svnrdump"? I've not explored it myself, but > don't see where it's a big advantage over a remote "ssh hostname > svnadmin dump" command, which avoids the kind of confusion I just > described. I'd start there, to avoid certain levels of uncertainty and > incompatibility with an out of date and no longer supported Subversion > release with a more modern tool that may not have been thoroughly > tested with it. What is interesting with svnrdump is that it is efficient to generate a "partial" dump, in term of revision range and selected path ! What "svnadmin dump" is not able to do without scanning a large part of the full repository (10 GiB)... Indeed you were right. As there is no merge tool for format 3 dumps, I decided to rsync over ssh the repository and run svnadmin dump on my workstation to avoid disturbing users. Thank you for that tip -- Yves Martin
Re: svnrdump produce a strange dump file
Hello, The problem I face now when using "svnadmin dump" is "svndumpfilter: E23: Invalid copy source path' when selecting the three /trunk modules I am interested in. Such a problem "svnrdump" does not produce. Thank you in advance for your help -- Yves Martin
Re: undo svnadmin pack
Hello, My version of fsfs-reshard script is able to unpack revisions and revision properties of a FSFS repository format 4 (Subversion 1.6) Probably there is not a lot of job to do to get it work with Subversion 1.8 format 6. I have already planned to work on it this month. https://github.com/ymartin59/svn-fsfs-reshard Regards -- Yves Martin
Re: Unexpected HTTP status 400 'Bad request'.
Hello Is your repository served read-write by other services like svnserve or eventually through SSH in addition to Apache HTTPS access ? If so you have to check your repository file permissions: owner, group and modes (for instance g+w or g+s...) I guess your repository has been created long ago with a previous version of Subversion. What is your repository format version ? Are some revisions packed ? Use svnadmin info. Maybe you should use "svnadmin upgrade" to get some new features properly enabled with Subversion 1.9, or even use dump/load procedure (or svnsync) to get your repository ready (and optimized) for Subversion 1.9. Regards -- Yves Martin
Re: Unexpected HTTP status 400 'Bad request'.
Hello, In my Apache2 configuration, I have added "LimitRequestBody 0" and "LimitXMLRequestBody 0" to avoid such troubles with a 12-year-old-really-large repository... Hope this helps Regards -- Yves Martin
Re: Unexpected HTTP status 400 'Bad request'.
Right. I also saw I have "LimitRequestFieldSize 6" set. Is it possible for you to open a clear HTTP virtual host so that to inspect Subversion client traffic and understand what may be wrong ? -- Yves Martin
Re: Unexpected HTTP status 400 'Bad request'.
Hello, Really your issue is strange. I propose you test your local checkout with HTTP protocol, with a tcpdump network traffic collection, maybe it is possible to find clues "on the wire". -- Yves Martin
Re: Unexpected HTTP status 400 'Bad request'.
Thanks Philip. Great tips. Just a remark: port to use in svn ls command is 9630 (instead of 9603) -- Yves Martin
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Hello, Have you checked disk space consumed by "pending" transactions (db/transactions) in your original 1.9 repository ? To clean up, use svnadmin lstxns and rmtxns. Hope this helps -- Yves Martin
Re: svn --diff-cmd not working
Hello,
Are you sure there are proper ${6} and ${7} arguments in any cases ?
You should add check in your script before invoking vim -d
I also recommend to end script with "exec /usr/bin/vim "
--
Yves Martin
Re: svn:mergeinfo updated for unchanged files/folders at merge of a feature branch to trunk - is this desirable?
On Sun, 2016-06-12 at 02:11 +0200, Branko Čibej wrote: > > It's not a result of merge of individual folders. I find the pattern > > in the log for commits I've done and I have most definitely not gone > > out of my way to explicitly merge several subfolders one-by-one. > > As I said, once the subtree mergeinfo is in the repository, it will be > updated in /every/ merge. > > > All users use TortoiseSVN. You think it's related to the client? > > Should I ask the Tortoise community instead? > > We'de really need a more detailed what's actually happening. I'm afraid > that for now we're only guessing based on your description of the logs; > that's far from enough. > > Personally, the few times I've used TortoiseSVN for merging, I didn't > notice it behaving in any way differently from the command-line client. Hello, The main issue is that merge operation will add a "svn:mergeinfo" at the current working directory where operation is applied. But it is expected to be only on "root" folder aka /trunk or /branches/xxx Two ways to avoid that: guidelines to developers when merging (often fails) and precommit hook to prevent addition of svn:mergeinfo property to "non-root" folders. To cleanup an existing working-copy, I have designed a Perl script that checks if a svn:mergeinfo may be "moved" up to "root" folder: https://github.com/ymartin59/svn-clean-mergeinfo It is not "perfect" (yet... do not hesitate to report issues with test cases) but it helps a lot to reduce svn:mergeinfo sets. Then a quick human check is required to finalize: remove remaning properties and commit the result. Hope this helps -- Yves Martin
Client connection timeout checkout/export/update
Hello, I am hosting a lot of repositories for my company projects since years and since server upgrade to 1.8 (from 1.6) some users report connection timeout when running their project checkout or export. My server is Debian Jessie, first running provided 1.8.10 packages but now WanDisco 1.8.16 packages. Protocol is either https or http, with WebDAV module in Apache 2.4.10 (from debian) Reports concern TortoiseSVN but I also reproduce connection timeout from Linux with latest 1.9.4 client package from WanDisco. checkout or export often stucks when processing zip files. What is even strange, svn process segfaults when running under strace, and also segfaults without strace some time. When interrupting client, another invocation gets further but stucks to other files. May it be possible these troubles come from 1.8 server-side caching logic or compression ? Thank you in advance for your help -- Yves Martin
Re: Client connection timeout checkout/export/update
Hello Ryan, My server runs with "MaxKeepAliveRequests 1" since Subversion 1.8 is available (client side issue) and I had no such troubles before upgrading server itself. I cannot go further investigating on production, I am switching to preproduction and try to reproduce there too. Thank you for your help -- Yves Martin
Re: Client connection timeout checkout/export/update
Hello, My subversion server uses mod_auth_kerb for authentication (SPNEGO or password) and AuthLDAP for permissions based on groups (since Subversion 1.3 or 1.4 I guess) If I discard my Kerberos TGT and use password authentication, Subversion client is able to export. There is chance mod_auth_kerb code dead-locks... What are recommended Kerberos SPNEGO settings for Apache2 on Linux with Subversion 1.8 ? Best regards -- Yves Martin
Re: Jira ticket notification hook?
On Wed, 2010-01-20 at 00:11 +0530, vishwajeet singh wrote: > > > On Tue, Jan 19, 2010 at 11:59 PM, Dave Levitt > wrote: > On Tue, Jan 12, 2010 at 1:53 PM, Aaron Turner > wrote: > > Hi Everyone, > > > > My company is moving from Trac (which has excellent SVN > integration) > > to Jira which seems to be a bit lacking. One big issue is > that we'd > > like people who are watching a ticket get a notification of > the commit > > when a commit references that ticket. Jira doesn't seem to > support > > that natively and most of our users don't want to be > notified about > > *every* commit- just the commits referencing tickets they > care about. > > > > I was hoping someone here was aware of a svn hook script > which > > implements this feature? > > > > Thanks, > > Aaron > > > > -- > > Aaron Turner > > http://synfin.net/ > > http://tcpreplay.synfin.net/ - Pcap editing and replay tools > for Unix & Windows > > Those who would give up essential Liberty, to purchase a > little temporary > > Safety, deserve neither Liberty nor Safety. > >-- Benjamin Franklin > > "carpe diem quam minimum credula postero" > > > > As I recall, Jira has a subversion plugin that looks for Jira > issue > numbers [e.g. FOO-123] in the body of the log message. Folks > watching > the FOO-123 issue would receive a notification from Jira a few > minutes > after the commit. > > The Jira svn plugin is located at > https://plugins.atlassian.com/plugin/details/291 > > > Thats true that Subversion plugin looks for issue numbers in log but > it does not trigger any notification if it finds one. > and also there is no way to do this out of the box in Jira. For my company, I have to modify the JIRA Subversion plugin so that a repository hook sends revision information to JIRA commit index (instead of JIRA system polling repository revisions). Reasons: a firewall between systems, heavy repository configuration at JIRA server side. Implementation details: - the post-commit hook is configured with expected patterns in log message - when a log matches, revision details are sent to JIRA Subversion plugin SOAP service - a specific event is triggered on matching tickets - this event is used in notification scheme to configure recipients Only ideas for the moment. No schedule yet.
