Files added to repository by others don't come down with 'svn update'
I first described my issue in the form of the Issue ticket: http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly closed for unclear reasons. The explanation in this ticket says "you somehow deleted your current directory". Well, I am positive I did not. In short: I had the checked out subversion directory. Somebody else added few files into the repository, then I deleted the enclosing sub-directory, updated it with 'svn update', and the added by others files failed to appear. And they also failed to appear after overall 'svn update'. What do I do now? I obviously have an invalid directory, and I didn't do anything wrong. I believe this indicates the presence of some problem in subversion. But this Issue has been assertively closed. Yuri
Re: Files added to repository by others don't come down with 'svn update'
I hope by "*Somebody else added few files into the repository*" You mean they have committed the file to the respository as well because just adding the file to repository would not make those available to others. It has to be committed as per SVN nomenclature. Just confirming before we jump to any conclusions. Thanks --- *Ashish Kaushik* | Team SourceFuse SourceFuse Technologies India (P) Ltd. http://www.sourcefuse.com --- On Thu, Jan 16, 2014 at 3:38 PM, Yuri wrote: > I first described my issue in the form of the Issue ticket: > http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was > promptly closed for unclear reasons. > The explanation in this ticket says "you somehow deleted your current > directory". Well, I am positive I did not. > > In short: I had the checked out subversion directory. Somebody else added > few files into the repository, then I deleted the enclosing sub-directory, > updated it with 'svn update', and the added by others files failed to > appear. And they also failed to appear after overall 'svn update'. > > What do I do now? I obviously have an invalid directory, and I didn't do > anything wrong. I believe this indicates the presence of some problem in > subversion. But this Issue has been assertively closed. > > Yuri >
Re: Files added to repository by others don't come down with 'svn update'
On Thu Jan 16 02:08:47 2014, Yuri wrote: > I first described my issue in the form of the Issue ticket: > http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly > closed for unclear reasons. There's nothing unclear about why your ticket was closed. Please read the top yellow box on our issue reporting page: http://subversion.apache.org/reporting-issues.html We don't put issues into the ticket system until we're sure they're actual bugs. We handle figuring out that they're actual bugs here. If a developer confirms your issue usually we'd ask you to file an issue, in this case we'd probably just reopen your issue. > The explanation in this ticket says "you somehow deleted your current > directory". Well, I am positive I did not. > > In short: I had the checked out subversion directory. Somebody else added few > files into the repository, then I deleted the enclosing sub-directory, > updated it with 'svn update', and the added by others files failed to appear. > And they also failed to appear after overall 'svn update'. > > What do I do now? I obviously have an invalid directory, and I didn't do > anything wrong. I believe this indicates the presence of some problem in > subversion. But this Issue has been assertively closed. I started to take a look at your issue but didn't get very far with it because the freebsd-ports tree is rather large and the checkout was taking a long time. So a much more specific recipe would be greatly helpful (hopefully one that doesn't require making a large checkout). So I'd follow the instructions here with respect to providing the reproduction recipe and environmental details: http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs I know that page says to send the email to the dev list but you can reply here since you've already started a thread.
Re: Files added to repository by others don't come down with 'svn update'
On Thu, Jan 16, 2014 at 02:08:47AM -0800, Yuri wrote: > I first described my issue in the form of the Issue ticket: > http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly > closed for unclear reasons. > The explanation in this ticket says "you somehow deleted your current > directory". Well, I am positive I did not. > > In short: I had the checked out subversion directory. Somebody else added > few files into the repository, then I deleted the enclosing sub-directory, > updated it with 'svn update', and the added by others files failed to > appear. And they also failed to appear after overall 'svn update'. This sounds as if you should have gotten a tree conflict marked in your working copy. Is this the case? If so, we can help you resolve it if you provide some additional details. If no tree conflict was flagged, then I'm not sure what state you're working copy is in and would need more information. Which Subversion client are you using, and which version? Do you have a command line client available? If so, can you check the output of 'svn status' when run on the problematic working copy? Does it mention tree conflicts? If you're unsure how to interpret the output please paste it into an email so others can see it. I'll explain what I see with Subversion 1.8 when I try to reproduce your problem based on the description you've given. A transcript of commands typed, and their output, is given below. I have a directory 'epsilon' in my working copy at r3. And I've locally deleted 'epsilon' in my working copy. In r4 a new file 'new.txt' was added to 'epsilon' in the repository. I update to r4 and get a tree conflict flagged, for which the client open a conflict resolution menu. There are two relevant options: (mc) prepare for updating moved-away children, if any (recommended) (p) postpone Because I didn't move any children out of epsilon before deleting it, I can just choose 'postpone'. To resolve the conflict, I revert the deletion of 'epsilon' which brings the newly added files back into my working copy (note that 'svn revert' removes conflict markers since reverting the working copy to its BASE revision implies the acceptance of the incoming conflicting change). If I then wanted to remove 'epsilon' again I could so by running 'svn rm epsilon'. The other option is to do nothing and keep the 'epsilon' directory as it is. Does this example help? If you're seeing a different problem, can you try to phrase your problem in a similar manner and provide a transcript? Thanks! $ svn status D epsilon D epsilon/zeta $ svn up Updating '.': C epsilon A epsilon/new.txt Updated to revision 3. Summary of conflicts: Tree conflicts: 1 Tree conflict on 'epsilon' > local dir delete, incoming dir edit upon update Select: (mc) prepare for updating moved-away children, if any (recommended), (p) postpone, (q) quit resolution, (h) help: p Summary of conflicts: Tree conflicts: 1 $ svn st D C epsilon > local dir delete, incoming dir edit upon update D epsilon/new.txt D epsilon/zeta Summary of conflicts: Tree conflicts: 1 $ svn revert -R epsilon Reverted 'epsilon' Reverted 'epsilon/zeta' Reverted 'epsilon/new.txt' $ ls epsilon/ new.txt zeta $ svn status $ svn rm epsilon D epsilon D epsilon/new.txt D epsilon/zeta $ svn status D epsilon D epsilon/new.txt D epsilon/zeta $
Re: Files added to repository by others don't come down with 'svn update'
On 01/16/2014 03:04, Ashish Kaushik wrote: I hope by "/Somebody else added few files into the repository/" You mean they have committed the file to the respository as well because just adding the file to repository would not make those available to others. It has to be committed as per SVN nomenclature. Yes, they committed the files into the repository. When I check out the fresh copy of this repository I see those files. But I don't see them in the original repository which I talked about in the description. Now I am looking into SQLite databases of this bad (damaged) repository and the good one (freshly checked out). I run this query on wc.db for one of the problematic files for both databases: "SELECT * FROM NODES where local_relpath like '%google-perftools%patch-static_vars%' order by local_relpath;" Good DB output: 1|devel/google-perftools/files/patch-static_vars.cc|0|devel/google-perftools/files|1|head/devel/google-perftools/files/patch-static_vars.cc|339827|normal|||file|(svn:eol-style native fbsd:nokeywords yes svn:mime-type text/plain)||$sha1$523055927a64af17578d4a64b9c10c05352b6e07||339812|1389815574658219|mandree|282|138979219100|(svn:wc:ra_dav:version-url 77 /ports/!svn/rvr/339812/head/devel/google-perftools/files/patch-static_vars.cc)|| Bad DB output: 1|devel/google-perftools/files/patch-static_vars.cc|0|devel/google-perftools/files|1|head/devel/google-perftools/files/patch-static_vars.cc|339905|normal|||file|(svn:mime-type text/plain svn:eol-style native fbsd:nokeywords yes)||$sha1$523055927a64af17578d4a64b9c10c05352b6e07||339812|1389815574658219|mandree|||(svn:wc:ra_dav:version-url 77 /ports/!svn/rvr/339812/head/devel/google-perftools/files/patch-static_vars.cc)|| 1|devel/google-perftools/files/patch-static_vars.cc|4|devel/google-perftools/filesbase-deleted|||file The major difference is that this file has two records in "Bad DB" and only one record in "Good DB". Bad DB has an extra record with op_depth=4 and 'base-deleted'. I never deleted those files, I added them myself locally because they are new, but never checked them in. And even if they were in local pending delete state, new files with the same path coming from the repository with update should at least cause the conflict. What do you think? Yuri
SVN client 1.8.x: unable to checkout public repositories when behind a web proxy
Hello all, I have come across the following situation: - With SVN client 1.8.x (specifically Tortoise 1.8.4), I'm not able to checkout public repositories when behind a (company) web proxy. You can try as an example to checkout from http://net-orcades-spring.googlecode.com/svn/trunk. - It works fine with SVN client 1.7.14. - If I try from home where I have direct access to Internet (i.e. no proxy), it works fine both ways (i.e. with SVN client 1.7.14 and with SVN client 1.8.4). - I am aware of some regressions introduced in 1.8.x (specifically in 1.8.0 and supposed to be fixed in 1.8.1) when switching from neon to serf but I am not sure if my problem is related to that. - I am not sure what SVN server version is used at googlecode, but according to their FAQ it is 1.6.x. I am mentioning this in case it matters. - Some reference I found in the Internet: o https://groups.google.com/forum/#!topic/tortoisesvn/3kJ-ybLF80A o http://subversion.tigris.org/issues/show_bug.cgi?id=4416 Do you think this is a bug? Should I add it in the SVN bug tracking tool? Let me know if you need additional information. Thanks, Ioannis
RE: SVN client 1.8.x: unable to checkout public repositories when behind a web proxy
Hi, We tested Subversion (and serf) with a number of different proxy servers and that worked correctly. Without knowledge of how we can reproduce your problem there is nothing we can do. And adding an issue to our issue tracker without something we can do is a complete waste of your (and our) time. So, perhaps it would help if you provide the errors you see and as much information as possible to allow us to help you. Bert From: Oikonomou Ioannis [mailto:ioannis.oikono...@trasysgroup.com] Sent: donderdag 16 januari 2014 12:23 To: d...@subversion.apache.org Cc: users@subversion.apache.org Subject: SVN client 1.8.x: unable to checkout public repositories when behind a web proxy Hello all, I have come across the following situation: - With SVN client 1.8.x (specifically Tortoise 1.8.4), I'm not able to checkout public repositories when behind a (company) web proxy. You can try as an example to checkout from http://net-orcades-spring.googlecode.com/svn/trunk. - It works fine with SVN client 1.7.14. - If I try from home where I have direct access to Internet (i.e. no proxy), it works fine both ways (i.e. with SVN client 1.7.14 and with SVN client 1.8.4). - I am aware of some regressions introduced in 1.8.x (specifically in 1.8.0 and supposed to be fixed in 1.8.1) when switching from neon to serf but I am not sure if my problem is related to that. - I am not sure what SVN server version is used at googlecode, but according to their FAQ it is 1.6.x. I am mentioning this in case it matters. - Some reference I found in the Internet: o https://groups.google.com/forum/#!topic/tortoisesvn/3kJ-ybLF80A o http://subversion.tigris.org/issues/show_bug.cgi?id=4416 Do you think this is a bug? Should I add it in the SVN bug tracking tool? Let me know if you need additional information. Thanks, Ioannis
Re: Files added to repository by others don't come down with 'svn update'
Yuri writes: > The major difference is that this file has two records in "Bad DB" and > only one record in "Good DB". Bad DB has an extra record with > op_depth=4 and 'base-deleted'. > > I never deleted those files, I added them myself locally because they > are new, but never checked them in. That would cause update to raise a tree-conflict on the file and mark it as base-deleted. > And even if they were in local > pending delete state, new files with the same path coming from the > repository with update should at least cause the conflict. It's in a "pending delete state" because that's what happened when the tree-conflict was raised. Either the tree-conflict is still present or you resolved it by accepting the current state. Either way the deleted file can be restored by running 'svn revert path/to/file'. Running update in the current state doesn't generate another tree-conflict because the file is already present and marked for deletion. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Space optimisation of a local checkout
Hello, I keep a local svn checkout in sync with a svn repository on the server (without making any local changes). I probably created the repository with subversion 1.6 (and also did the checkout with the same version) and later upgraded both the original repository and the checkout to version 1.8. (I dumped and imported the original repository and ran "svn upgrade" on the checkout.) The size of a checkout (excluding .svn) is 659 MB. The size of original repository dropped from 653 to 601 MB when I upgraded it to version 1.8 and now increased again to 738 MB due to new commits. But the weird thing is that the size of .svn folder in a local checkout is 2.7 GB. If I do a fresh checkout it's only 659M which is reasonable, but 2.7 GB seems too much. I then checked another checkout of a large repository. The size of the checkout is 6,3 GB, but the .svn folder apparently became a 36 GB monster. Is there any painless way to shrink the size of the local .svn folder (other than deleting everything and fetching the whole 6 GB again)? Thank you, Mojca
Re: Space optimisation of a local checkout
On Thu, Jan 16, 2014 at 02:49:56PM +0100, Mojca Miklavec wrote: > Hello, > > I keep a local svn checkout in sync with a svn repository on the > server (without making any local changes). > > I probably created the repository with subversion 1.6 (and also did > the checkout with the same version) and later upgraded both the > original repository and the checkout to version 1.8. (I dumped and > imported the original repository and ran "svn upgrade" on the > checkout.) > > The size of a checkout (excluding .svn) is 659 MB. The size of > original repository dropped from 653 to 601 MB when I upgraded it to > version 1.8 and now increased again to 738 MB due to new commits. > > But the weird thing is that the size of .svn folder in a local > checkout is 2.7 GB. If I do a fresh checkout it's only 659M which is > reasonable, but 2.7 GB seems too much. > > I then checked another checkout of a large repository. The size of the > checkout is 6,3 GB, but the .svn folder apparently became a 36 GB > monster. > > Is there any painless way to shrink the size of the local .svn folder > (other than deleting everything and fetching the whole 6 GB again)? > > Thank you, > Mojca 'svn cleanup' http://subversion.apache.org/docs/release-notes/1.7.html#wc-pristines
Re: Space optimisation of a local checkout
Mojca Miklavec writes: > Is there any painless way to shrink the size of the local .svn folder > (other than deleting everything and fetching the whole 6 GB again)? 'svn cleanup' -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: How to "un-checkout" from svn
Though this is years late.. I believe what you want is to do the command: svn update --set-depth exclude It is documented here: http://svnbook.red-bean.com/en/1.6/svn.advanced.sparsedirs.html -- View this message in context: http://subversion.1072662.n5.nabble.com/How-to-un-checkout-from-svn-tp132246p186633.html Sent from the Subversion Users mailing list archive at Nabble.com.
How to recreate rep-cache.db if it wasn't writable for some time ?
(please CC: me as not subscribed) Hi. The bug report "rep-cache.db created without group write bit" [0] seems to be on the way of being solved (AFAIU, the fix isn't released yet). So, until then, for new repositories where no commit was made, a workaround is to create (touch) the file before the first commit. But if commits have been made already, as the file was created with wrong permissions, there are chances that some commits are missing. I cannot seem to find a reference to a repair solution to recreate the contents of the DB cache (svnadmin recover doesn't address it AFAICT). The document at [1] mentions that "This file is only consulted during writes and never during reads. Consequently, it is not required, and may be removed at an abritrary time, with the subsequent loss of rep-sharing capabilities for revisions written thereafter." But AFAIU, if the file is removed, it gets recreated anyway, staring from the next commit, unless enable-rep-sharing = false... So I'm wondering : if the file is incomplete, is there a risk ? And if not, how may we recreate the contents of the cache ? It seems that the algorithm would be quite simple from reading [1], but that's beyond my capacity investigating SVN internals, I'm afraid. Thanks in advance. Best regards, [0] http://subversion.tigris.org/issues/show_bug.cgi?id=3437 [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
SIGSERV on 'svn update'
Hi. I got a SIGSERV error while running 'svn update'. I have Debian 7.1 (3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686) with svn, version 1.6.17 (r1128011) compiled Oct 4 2013, 03:24:06 (from Debian portage tree) I ran it under gdb: (gdb) run up Starting program: /usr/bin/svn up [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0xb7eebd41 in ?? () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 (gdb) bt #0 0xb7eebd41 in ?? () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #1 0xb7eec250 in ?? () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #2 0xb7eec698 in svn_utf_cstring_to_utf8 () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #3 0xb7ede22c in svn_path_cstring_to_utf8 () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #4 0xb7ece8fe in ?? () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #5 0xb7ed3e08 in svn_io_get_dir_filenames () from /usr/lib/i386-linux-gnu/libsvn_subr-1.so.1 #6 0xb7f369f3 in ?? () from /usr/lib/i386-linux-gnu/libsvn_wc-1.so.1 #7 0xb7f377fd in svn_wc_crawl_revisions4 () from /usr/lib/i386-linux-gnu/libsvn_wc-1.so.1 #8 0xb7fb79bf in svn_client__update_internal () from /usr/lib/i386-linux-gnu/libsvn_client-1.so.1 #9 0xb7fb7df6 in svn_client_update3 () from /usr/lib/i386-linux-gnu/libsvn_client-1.so.1 #10 0x0805cfe1 in ?? () #11 0x0804e176 in ?? () #12 0xb7d1be46 in __libc_start_main (main=0x804c330, argc=2, ubp_av=0xbbb4, init=0x805f450, fini=0x805f440, rtld_fini=0xb7ff0590, stack_end=0xbbac) at libc-start.c:228 #13 0x0804e7b1 in ?? () The problem happens on a huge svn project, so it's very hard to reduce it to a small reproduction recipe. I think that the problem might be caused by using ru_RU.KOI8-R as a default system locale. Is this problem already known? Best regards, Alexander -- Alexander V. Smal St. Petersburg Department of Steklov Mathematical Institute 27 Fontanka, St. Petersburg, 191023, Russia -- Alexander V. Smal St. Petersburg Department of Steklov Mathematical Institute 27 Fontanka, St. Petersburg, 191023, Russia
SVN 1.8.x erroneously assumes a reintegrate merge and gives error E195016
We are running into an issue similar to the one described in http://svn.haxx.se/users/archive-2013-12/0171.shtml when performing some sync merges. svn issues error "E195016: Reintegrate can only be used if revisions…” but this isn’t a reintegrate merge. When this happens, the only work around appears to be to specify the revision range to merge explicitly, which is very confusing and error prone for less experienced users. Is there something we can do to help svn’s reintegrate logic work better? Note that this is not the dropped character problem described in other posts. We have confirmed that all of the paths in svn:mergeinfo are correct.
Bug ? With SVN 1.8.4 on Mac
Hi, i observed a strange thing during a checkin process running where i got the following messages: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff Sendingsrc/it/mexec-100/pom.xml Sendingsrc/it/mexec-105/pom.xml Transmitting file data .. Committed revision 19310. svn: E120108: Commit failed (details follow): svn: E120108: Error running context: The server unexpectedly closed the connection. svn: E120108: Additional errors: svn: E120108: Error running context: The server unexpectedly closed the connection. BUT: On my build server this version is already being used: 19:17:54 Updating https://svn.codehaus.org/mojo/trunk/mojo/exec-maven-plugin at revision '2014-01-16T19:17:39.738 +0100' 19:17:57 U src/it/mexec-100/pom.xml 19:17:57 U src/it/mexec-105/pom.xml 19:17:57 At revision 19310 This means for me the above error message is simply wrong, cause the revision has already been committed into the repository...and could be used and has been use for an update... Anything known about this ? Kind regards Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de
Re: Bug ? With SVN 1.8.4 on Mac
Hi, furthermore i have recodnized that the local files are currently in the state of modified: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn st M src/it/mexec-100/pom.xml M src/it/mexec-105/pom.xml which is really strange, cause the files i have changed the above two pom files have already been used on my build server. BTW: My SVN Environment: svn, version 1.8.4 (r1534716) compiled Oct 25 2013, 11:02:47 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.2.1 - handles 'http' scheme - handles 'https' scheme On 1/16/14 7:23 PM, Karl Heinz Marbaise wrote: Hi, i observed a strange thing during a checkin process running where i got the following messages: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff Sendingsrc/it/mexec-100/pom.xml Sendingsrc/it/mexec-105/pom.xml Transmitting file data .. Committed revision 19310. svn: E120108: Commit failed (details follow): svn: E120108: Error running context: The server unexpectedly closed the connection. svn: E120108: Additional errors: svn: E120108: Error running context: The server unexpectedly closed the connection. BUT: On my build server this version is already being used: 19:17:54 Updating https://svn.codehaus.org/mojo/trunk/mojo/exec-maven-plugin at revision '2014-01-16T19:17:39.738 +0100' 19:17:57 U src/it/mexec-100/pom.xml 19:17:57 U src/it/mexec-105/pom.xml 19:17:57 At revision 19310 This means for me the above error message is simply wrong, cause the revision has already been committed into the repository...and could be used and has been use for an update... Anything known about this ? Kind regards Karl-Heinz Marbaise Kind regards Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de
Re: Bug ? With SVN 1.8.4 on Mac
On Thu, Jan 16, 2014 at 1:23 PM, Karl Heinz Marbaise wrote: > i observed a strange thing during a checkin process running where i got > the following messages: > > Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff > Sendingsrc/it/mexec-100/pom.xml > Sendingsrc/it/mexec-105/pom.xml > Transmitting file data .. > Committed revision 19310. > It looks like the commit worked. > svn: E120108: Commit failed (details follow): > svn: E120108: Error running context: The server unexpectedly closed the > connection. > svn: E120108: Additional errors: > svn: E120108: Error running context: The server unexpectedly closed the > connection. > And the failure came in the post-commit updating of your working copy to reflect this. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Bug ? With SVN 1.8.4 on Mac
Hi, so after i did an svn up i got this: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn up Updating '.': Gsrc/it/mexec-100/pom.xml Gsrc/it/mexec-105/pom.xml more or less expected > Hi, furthermore i have recodnized that the local files are currently in the state of modified: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn st M src/it/mexec-100/pom.xml M src/it/mexec-105/pom.xml which is really strange, cause the files i have changed the above two pom files have already been used on my build server. BTW: My SVN Environment: svn, version 1.8.4 (r1534716) compiled Oct 25 2013, 11:02:47 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.2.1 - handles 'http' scheme - handles 'https' scheme On 1/16/14 7:23 PM, Karl Heinz Marbaise wrote: Hi, i observed a strange thing during a checkin process running where i got the following messages: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff Sendingsrc/it/mexec-100/pom.xml Sendingsrc/it/mexec-105/pom.xml Transmitting file data .. Committed revision 19310. svn: E120108: Commit failed (details follow): svn: E120108: Error running context: The server unexpectedly closed the connection. svn: E120108: Additional errors: svn: E120108: Error running context: The server unexpectedly closed the connection. BUT: On my build server this version is already being used: 19:17:54 Updating https://svn.codehaus.org/mojo/trunk/mojo/exec-maven-plugin at revision '2014-01-16T19:17:39.738 +0100' 19:17:57 U src/it/mexec-100/pom.xml 19:17:57 U src/it/mexec-105/pom.xml 19:17:57 At revision 19310 This means for me the above error message is simply wrong, cause the revision has already been committed into the repository...and could be used and has been use for an update... Anything known about this ? Kind regards Karl-Heinz Marbaise Kind regards Karl-Heinz Marbaise Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de
Re: SVN 1.8.x erroneously assumes a reintegrate merge and gives error E195016
On 1/16/14, 8:34 AM, Keath Milligan wrote: > We are running into an issue similar to the one described in > http://svn.haxx.se/users/archive-2013-12/0171.shtml when performing some sync > merges. svn issues error "E195016: Reintegrate can only be used if > revisions…” but this isn’t a reintegrate merge. When this happens, the only > work around appears to be to specify the revision range to merge explicitly, > which is very confusing and error prone for less experienced users. > > Is there something we can do to help svn’s reintegrate logic work better? > > Note that this is not the dropped character problem described in other posts. > We have confirmed that all of the paths in svn:mergeinfo are correct. Can you provide a minimal reproduction recipe (starting with a new repository) that demonstrates the issue? It's very difficult to diagnose merge issues without looking at the repository (which I'm going to assume you can't let us do, though if you could that may be helpful) because the history is very important to the behavior of merge. Some general guidelines on how to report a bug are here: http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
Re: Space optimisation of a local checkout
On Thu, Jan 16, 2014 at 3:03 PM, Stefan Sperling wrote: > On Thu, Jan 16, 2014 at 02:49:56PM +0100, Mojca Miklavec wrote: >> >> Is there any painless way to shrink the size of the local .svn folder >> (other than deleting everything and fetching the whole 6 GB again)? > > 'svn cleanup' > http://subversion.apache.org/docs/release-notes/1.7.html#wc-pristines Thank you very much for both the answer and the link (which includes the link to the tracker). Mojca
Re: How to recreate rep-cache.db if it wasn't writable for some time ?
On 1/16/14, 6:08 AM, Olivier Berger wrote: > (please CC: me as not subscribed) > > Hi. > > The bug report "rep-cache.db created without group write bit" [0] seems > to be on the way of being solved (AFAIU, the fix isn't released yet). Correct, no release includes this yet. I don't think it's been nominated either. I'll poke Philip about his intentions here. > I cannot seem to find a reference to a repair solution to recreate the > contents of the DB cache (svnadmin recover doesn't address it AFAICT). > > The document at [1] mentions that "This file is only consulted during > writes and never during reads. Consequently, it is not required, and > may be removed at an abritrary time, with the subsequent loss of > rep-sharing capabilities for revisions written thereafter." But AFAIU, > if the file is removed, it gets recreated anyway, staring from the next > commit, unless enable-rep-sharing = false... > > So I'm wondering : if the file is incomplete, is there a risk ? And > if not, how may we recreate the contents of the cache ? Right now there's no way to do this other than a dump/load cycle since the only place the rep cache is written is during a commit. For what it's worth I recall mentioning to Stefan Fuhrmann that we didn't seem to have a way to rebuild the db and I have a hazy memory of him telling me that we did. Looking at the code however, makes me think we don't (and I even looked at trunk). Now as to your comment about risk. There is no risk. If the file is missing or incomplete it won't break anything. The only issue is that if commits are missing then the representations they wrote cannot be used to avoid writing identical new representations. The end result of this is that your repository may be bigger. > It seems that the algorithm would be quite simple from reading [1], but > that's beyond my capacity investigating SVN internals, I'm afraid. You're right it should be relatively easy to write some code to rebuild it (I suspect figuring out where this functionality should go from a UI perspective will be harder than writing the code). Even if we had functionality to rebuild this db, if you're concerned about this it'd still probably be best to do a dump/load. Simply because if you weren't writing the rep-cache while some revisions were committed, then some of those revisions may contain duplicate representations. So you repository might still be slightly bigger. However, we ought to be able to detect that and tell you that you repo would shrink if you ran a dump/load. In fact that might be a useful feature to admins trying to decide if a dump/load is worth it (time vs space).
Re: SVN 1.8.x erroneously assumes a reintegrate merge and gives error E195016
Thanks Ben, we are unable to reproduce this in a simple repo but we are continuing to investigate. We did notice something odd in the mergeinfo of the affected branch though. It lists a set of revisions for *itself*, which we don’t see elsewhere. Is this valid? This repo has had a lot of activity, but we think this may have happened when it was deleted and recreated at one point (and possibly had revisions cherry-picked into it).
Re: Bug ? With SVN 1.8.4 on Mac
Karl Heinz Marbaise writes: > Hi, > > so after i did an svn up i got this: > > Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn up > Updating '.': > Gsrc/it/mexec-100/pom.xml > Gsrc/it/mexec-105/pom.xml > > more or less expected > >> furthermore i have recodnized that the local files are currently in the >> state of modified: >> >> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn st >> M src/it/mexec-100/pom.xml >> M src/it/mexec-105/pom.xml >> >>> i observed a strange thing during a checkin process running where i got >>> the following messages: >>> >>> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff >>> Sendingsrc/it/mexec-100/pom.xml >>> Sendingsrc/it/mexec-105/pom.xml >>> Transmitting file data .. >>> Committed revision 19310. >>> svn: E120108: Commit failed (details follow): >>> svn: E120108: Error running context: The server unexpectedly closed the >>> connection. >>> svn: E120108: Additional errors: >>> svn: E120108: Error running context: The server unexpectedly closed the >>> connection. E120108 is unknown on my Linux box: $ ../src/tools/dev/which-error.py E120108 00120108 *** UNKNOWN ERROR CODE *** The client recognises SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED (165007) as a failed post-commit so the unknown E120108 meant the client didn't do post-commit processing so the committed files showed up as uncommitted. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Bug ? With SVN 1.8.4 on Mac
Philip Martin writes: Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff Sendingsrc/it/mexec-100/pom.xml Sendingsrc/it/mexec-105/pom.xml Transmitting file data .. Committed revision 19310. svn: E120108: Commit failed (details follow): svn: E120108: Error running context: The server unexpectedly closed the connection. svn: E120108: Additional errors: svn: E120108: Error running context: The server unexpectedly closed the connection. > > E120108 is unknown on my Linux box: > > $ ../src/tools/dev/which-error.py E120108 > 00120108 *** UNKNOWN ERROR CODE *** I think that might be SERF_ERROR_ABORTED_CONNECTION. Is that an error the commiting client generated while reading the response from the server or a server error returned to the committing client? The committing client seems to have received enough of the response to get the new revision number. -- Philip
"svn log --xml -g" doesn't identify a reverse merge but "svn log -g" does
I need a sanity check. Is this an oversight that needs to be corrected, or am
I missing something?
Problem:
"svn log -g" will explicitly identify a reverse merge, however, when specifying
xml output ("svn log -g --xml") no such identification is made.
Example:
In this case, r13 on branches/test was merged to trunk (which created r15 on
trunk.) I then reverse merged the r13 change out of trunk using "svn merge -c
-15".
a) "svn log -g -v" explicitly states that r13 was "Reverse merged via..":
r17 | andrew | 2014-01-16 14:41:15 -0500 (Thu, 16 Jan 2014) | 1 line
Changed paths:
M /trunk
M /trunk/a.txt
svn merge -c -15 .
r13 | andrew | 2014-01-16 14:37:17 -0500 (Thu, 16 Jan 2014) | 1 line
Changed paths:
M /branches/test/a.txt
==> Reverse merged via: r17
branch 3
b) However, "svn log -g -v --xml" does not indicate that it was a reverse merge:
andrew
2014-01-16T19:41:15.571931Z
/trunk
/trunk/a.txt
svn merge -c -15 .
==>
andrew
2014-01-16T19:37:17.531316Z
/branches/test/a.txt
branch 3
Andrew Reedick
CBeyond
Cloud Development, SCM
O: 678.486.8163
RE: Bug ? With SVN 1.8.4 on Mac
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: donderdag 16 januari 2014 20:59 > To: i...@soebes.de > Cc: users@subversion.apache.org > Subject: Re: Bug ? With SVN 1.8.4 on Mac > > Karl Heinz Marbaise writes: > > > Hi, > > > > so after i did an svn up i got this: > > > > Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn up > > Updating '.': > > Gsrc/it/mexec-100/pom.xml > > Gsrc/it/mexec-105/pom.xml > > > > more or less expected > > > >> furthermore i have recodnized that the local files are currently in the > >> state of modified: > >> > >> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn st > >> M src/it/mexec-100/pom.xml > >> M src/it/mexec-105/pom.xml > >> > >>> i observed a strange thing during a checkin process running where i got > >>> the following messages: > >>> > >>> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff > >>> Sendingsrc/it/mexec-100/pom.xml > >>> Sendingsrc/it/mexec-105/pom.xml > >>> Transmitting file data .. > >>> Committed revision 19310. > >>> svn: E120108: Commit failed (details follow): > >>> svn: E120108: Error running context: The server unexpectedly closed the > >>> connection. > >>> svn: E120108: Additional errors: > >>> svn: E120108: Error running context: The server unexpectedly closed the > >>> connection. > > E120108 is unknown on my Linux box: > > $ ../src/tools/dev/which-error.py E120108 > 00120108 *** UNKNOWN ERROR CODE *** > > The client recognises SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED > (165007) as > a failed post-commit so the unknown E120108 meant the client didn't do > post-commit processing so the committed files showed up as uncommitted. That error code looks like the platform specific error code for "The server unexpectedly closed the connection.". That script is only going to help you for the platform invariant error codes in Subversion itself + the codes on the platform you are checking on. Bert
Re: Bug ? With SVN 1.8.4 on Mac
On 1/16/14, 12:34 PM, Bert Huijben wrote: > That script is only going to help you for the platform invariant error codes > in Subversion itself + the codes on the platform you are checking on. It knows about APR's errors as well (not that this is important in this case), see the aprerr.txt file in tools/dev
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn log -g" does
On 1/16/14, 12:31 PM, Andrew Reedick wrote:
> I need a sanity check. Is this an oversight that needs to be corrected, or
> am I missing something?
>
> Problem:
> "svn log -g" will explicitly identify a reverse merge, however, when
> specifying xml output ("svn log -g --xml") no such identification is made.
Yup looks like an oversight. The nesting already shows that it's a merge and
what revision made the merge. But we don't show the direction of the merge.
I've coded up a trivial change to add a reverse-merge attribute on the logentry
element in this case. e.g.
Once I write a test for it I'll commit it.
Given that it changes the XML output, I probably wouldn't backport this to
1.8.x.
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn log -g" does
On 1/16/14, 1:38 PM, Ben Reser wrote:
> On 1/16/14, 12:31 PM, Andrew Reedick wrote:
>> I need a sanity check. Is this an oversight that needs to be corrected, or
>> am I missing something?
>>
>> Problem:
>> "svn log -g" will explicitly identify a reverse merge, however, when
>> specifying xml output ("svn log -g --xml") no such identification is made.
>
> Yup looks like an oversight. The nesting already shows that it's a merge and
> what revision made the merge. But we don't show the direction of the merge.
>
> I've coded up a trivial change to add a reverse-merge attribute on the
> logentry
> element in this case. e.g.
>
>
> Once I write a test for it I'll commit it.
>
> Given that it changes the XML output, I probably wouldn't backport this to
> 1.8.x.
Opened issue #4463 for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4463
Re: "svn log --xml -g" doesn't identify a reverse merge but "svn log -g" does
On 1/16/14, 1:59 PM, Ben Reser wrote: > Opened issue #4463 for this: > http://subversion.tigris.org/issues/show_bug.cgi?id=4463 Fixed in r1559032. I anticipate that the fix will be included in 1.9.0.
