bug
--- 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.4\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1550: assertion failed (action == svn_wc_conflict_action_delete) --- 确定 ---
Upgrade SVN from version 1.5.6 (r36142) to 1.8.5
Hello; I'm planning to upgrade my SVN from version 1.5.6 (r36142) to 1.8.5 and i wanna know if i need to do some "special" steps to perform this. Thanks in advance!! -- Guido
Re: Upgrade SVN from version 1.5.6 (r36142) to 1.8.5
On Thu, Feb 13, 2014 at 10:57:15AM -0200, Guido Larrain wrote: > Hello; > > I'm planning to upgrade my SVN from version 1.5.6 (r36142) to 1.8.5 and i > wanna know if i need to do some "special" steps to perform this. > > Thanks in advance!! > > -- > Guido The most special step (most people don't seem to do this ;) is to read the upgrade documentation in the release notes for each intermediate release (1.6 to 1.8 in your case), which document the special steps, if any, better than any subscriber of this list could recite from memory. http://subversion.apache.org/docs/release-notes/1.6.html#compatibility http://subversion.apache.org/docs/release-notes/1.7.html#compatibility http://subversion.apache.org/docs/release-notes/1.8.html#compatibility If you still have questions after reading, feel free to ask.
Re: Unable to browse repo
Dave, Thank you for the tip...that fixed the issue. Best regards, Amad On Wed, Feb 12, 2014 at 11:50 AM, Dave Huang wrote: > On 2014-02-12 11:46 AM, C M wrote: > >> For what it's worth, line 93 refers in the config file is listed below. >> As far as I know, this file hasn't been modfied recently by anyone. At >> least that's what my team members tell me. >> >> >> 92 ### put last-committed timestamps on every file touched. >> 93 use-commit-times = yes >> 94 ### Set no-unlock to prevent 'svn commit' from automatically >> > > It looks like there's a space at the beginning of line 93... try removing > it. > >
Full repository merge info?
Hi, I need to cache all the merges made on a repository in order to rebuild the full merge history of any item (file/directory) at any time (revision). How it can be achieved? For example, in order to cache the full history of a repository svn -log -v REPO_ROOT_URL would made the job as it returns all the revisions and their changed paths (added, modified...). With such info is feasible to build the history of any item as TortoiseSVN does for revision graphs. it would be possible get the same for merging by adding -g to the command above? Thanks, Pablo
RE: Upgrade SVN from version 1.5.6 (r36142) to 1.8.5
Hi Guido, > -Original Message- > From: Stefan Sperling > Sent: Friday, 14 February 2014 1:03 AM > > On Thu, Feb 13, 2014 at 10:57:15AM -0200, Guido Larrain wrote: > > Hello; > > > > I'm planning to upgrade my SVN from version 1.5.6 (r36142) to 1.8.5 > > and i wanna know if i need to do some "special" steps to > perform this. Is that the client or the server? If it's the client, you should have no problems. The only potential problem will be if you have working copies on a shared drive (it's not recommended, but it happens) and other people who access these are using different versions. If it's the server, you might need to upgrade any BDB repositories to FSFS. Regardless, read the notes on the links that Stefan provided. > > Thanks in advance!! > > > > -- > > Guido > > The most special step (most people don't seem to do this ;) > is to read the upgrade documentation in the release notes for > each intermediate release (1.6 to 1.8 in your case), which > document the special steps, if any, better than any > subscriber of this list could recite from memory. > > http://subversion.apache.org/docs/release-notes/1.6.html#compatibility > http://subversion.apache.org/docs/release-notes/1.7.html#compatibility > http://subversion.apache.org/docs/release-notes/1.8.html#compatibility > > If you still have questions after reading, feel free to ask. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Bug report on SVN 1.8.3 Cannot allocate Memory
Hi Ben I just posted my questions on http://post.gmane.org I'm not sure if it is posted on the mailing list yet. Anyway, I also decide to send it directly to you guys. If this is not the right way to approach, please pardon me and let me know. Here is my comments that I posted on http://post.gmane.org The Linux VM test machine showed it is the OOM error. Below is the error when I run the command dmesg Out of memory: Kill process 4353 (httpd) score 134 or sacrifice child Killed process 4353, UID 41000, (httpd) total-vm:2850244kB, anon-rss:690052kB, file-rss:28kB This Linux VM machine has Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 SVN/1.8.5 configured. >From this error message, the httpd process was killed which seem to me it >either has something to do with the Apache server or SVN 1.8 itself ?? We download this release of subversion from Collabnet. It bundles subversion and apache together so we don't modify the apache configuration to have the correc modules. Have anyone ran into this OOM issue with subversion 1.8 and Apache 2.2.25 configuration? Could you please help to shed some light on this? Let me know if you need any additional information. -Original Message- From: Ben Reser [mailto:b...@reser.org] Sent: Thursday, December 12, 2013 3:37 PM To: Nguyen, Quyen; users@subversion.apache.org Cc: Vornbrock, Beth Subject: Re: Bug report on SVN 1.8.3 Cannot allocate Memory On 12/12/13 2:12 PM, Nguyen, Quyen wrote: > Looking into the subversion error_log and it appears it point to the > memory > > [Mon Nov 18 17:28:53 2013] [error] [client 10.20.36.51] Can't start > process > '/data00start-commit': Cannot allocate memory [500, #12] That is an OS error. Subversion is providing you the "Cannot allocate memory" message as a convenience, it's not producing the error. Looking at the code I'd bet that fork() is returning ENOMEM on your system. > Our Linux System Admin had applied different memory cache setting to > the server but thus far we have no luck resolving this error. > > If you could please provide any insights on why and ho we could > correct this issue, I'm truly appreciated your help/ Add more memory to the system or figure out why the kernel doesn't think it has enough memory. Might want to check your configured ulimits as well. This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.
Re: New svn client format (1.7+) breaks when checkout crosses filesystems
First, thanks for your answer, and sorry my late answer On Mon, Feb 03, 2014 at 03:05:28PM -0800, Ben Reser wrote: > On 2/3/14, 2:26 PM, Marc MERLIN wrote: > > On my personal system, I got a new svn and as prompted by "your repo is > > too old", upgraded it to the new format (svn 1.7.13). > > You mean working copy, there is no such message about repositories. We > support > repositories all the way back to 1.0. Yes, I did. After working with svn, p4, and git, I tend to confuse the terms a bit, sorry. > It's no longer supported for a working copy to cross file systems. > Unfortunately, doesn't look like we documented that fact in our release notes: > http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng So be it. Maybe it would be good for svn upgrade to notice this and fail, or at least print a warning? > This has caused some issues on Windows as well where permissions become > problematic because the files are not made under the same directory as their > destination. So it's possible we might change this in the future. But that > does nothing to help you right now. Indeed :) but I appreciate the info nonetheless. > > I don't really want to rebuild my entire svn checkout in 7 different ones > > (one > > per filesystem), not counting that I'd have to manually fix what svn state > > that > > isn't synced on each of my client checkouts. > > > > What are my options? > > 1) revert to svn 1.6 but I don't think I can revert my svn repo state > > without going back to backups, I'm assuming it's a one way upgrade. > > Before starting it would be a good idea to take a backup of the files if you > have concerns about local modifications. Sound advise. > Note what revision you're at in your working copy with svnversion (I'll assume > $WC is your $WC root from here on out) > svnversion $WC Good idea, but: legolas:/var/local/scr# svnversion svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted legolas:/var/local/scr# svnversion / svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted > Hopefully that's not a mixed revision range, if it is you may have some issues > with the following. If it's locally modified that should be ok. > > Remove the .svn working copy metadata directory: > rm -rf $WC/.svn > > Run the checkout again with 1.6 client where $REV is the revision you got from > svnversion and $URL is the $URL to your repo: > svn-1.6 checkout --force -r $REV $URL $WC > > You'll get a lot of E lines (which is the client saying the file already > exists). It'll still have your local modifications. Thanks for the tip. I'll try some of that on one client, but on the others I probably > However, we no longer support 1.6, so you probably want to upgrade to 1.7/1.8 > at some point or you're going to be stuck in the past. I know, I lose, I'll have to rebuild my entire system. Maybe I'll just switch away from svn considering how much work it'll be anyway. > This (splitting your working copy) is probably your best bet. However, to be > honest with you this was never a task to which Subversion was made for. I'm Apparently not. I used to do this with cvs, then upgraded to svn, now maybe to something else. I understand that my use case is clearly not a majority so I'll deal. > guessing you're already using some sort of wrapper to deal with permissions. actually I don't because I only check config files and scripts that do not need special owners or permissions. > So it seems to me you need to extend the wrapper to deal with multiple working > copies on each file system and keeping them in sync. More than likely you > need > to request the latest revision from the server (1.7/1.8: use svn info $URL and > pull out the Revision: field; 1.9 will have svn youngest for this purpose). > Then run svn up -r $REV on each working copy. > > > 3) other :) > > I don't see any other choices. Thanks for laying down the options, it definitely helps me plan about what I should do next. Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
To decide whether merge should be done or not
Hi Team, Whenever there is merge operation being performed by the user, I want to decide whether the merge should be allowed or not based on certain conditions. I was wondering whether the start-commit hook script can be modified for this. But, does the merge actually invoke the start-commit script before it begins the merge operation? Can anyone help me on this to understand the merge operation & do necessary changes? Thanks in advance. Regards, Reshma -- View this message in context: http://subversion.1072662.n5.nabble.com/To-decide-whether-merge-should-be-done-or-not-tp187121.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: To decide whether merge should be done or not
A merge commit in subversion is no different than a regular commit. It will cause start-commit, pre-commit and post-commit hooks to be executed. Regards, Arwin Arni On Fri, Feb 14, 2014 at 11:57 AM, ReshmaBabu wrote: > Hi Team, > > Whenever there is merge operation being performed by the user, I want to > decide whether the merge should be allowed or not based on certain > conditions. > I was wondering whether the start-commit hook script can be modified for > this. But, does the merge actually invoke the start-commit script before it > begins the merge operation? Can anyone help me on this to understand the > merge operation & do necessary changes? > > Thanks in advance. > > Regards, > Reshma > > > > -- > View this message in context: > http://subversion.1072662.n5.nabble.com/To-decide-whether-merge-should-be-done-or-not-tp187121.html > Sent from the Subversion Users mailing list archive at Nabble.com. >
