merginfo corruption?
Hi, Recently we have been having multiple instances of a problem that doesn't seem to be going away. The easiest way to see it is to reproduce the following steps. 1) check out a working copy of one of our development branches: svn co svn://svn.nublado.org/cloudy/branches/backtrace Changes from the trunk were last merged to this branch in r11144. This checkout looks fine and I want to merge the more recent changes from the trunk. So cd into it and proceed. 2) First take a look at which revisions are eligible: svn mergeinfo --show-revs eligible ^/trunk . r11156 r11159 r11160 r11165 r11166 r11167 [ snip... ] r11337 r11338 r11339 r11340 r11341 This all looks very plausible. The first commit to the trunk after r11144 is r11156 and the last is r11341. All numbers shown above are correct. I didn't check all the numbers I cut out, but I assume they are correct as well. 3) All looks fine, so do the merge: svn merge ^/trunk . --- Merging r8669 into 'source': Csource/rt_continuum_shield_fcn.cpp --- Recording mergeinfo for merge of r8667 through r8669 into '.': U . --- Recording mergeinfo for merge of r8667 through r8669 into 'source': U source Summary of conflicts: Text conflicts: 1 Conflict discovered in file 'source/rt_continuum_shield_fcn.cpp'. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options: ^CSummary of conflicts: Text conflicts: 1 svn: E155027: Unable to resolve conflicts on '/home/pvh/noot/backtrace/source/rt_continuum_shield_fcn.cpp' I hit ^C here. So all of a sudden svn wants to merge r8669, even though it was not marked as eligible before (and was already merged a long time ago)... So what is this? Corrupted information in the svn:mergeinfo propety? A bug in svn? Or both? And more importantly how do I fix this? I tried doing this brute-force approach svn revert -R . svn merge --record-only -r1:11144 ^/trunk . --- Merging r2 through r11144 into '.': G tsuite/auto G tsuite G . --- Recording mergeinfo for merge of r2 through r11144 into '.': U . --- Recording mergeinfo for merge of r2 through r11144 into 'data/lamda/masterlist/Lamda.ini': U data/lamda/masterlist/Lamda.ini --- Recording mergeinfo for merge of r2 through r11144 into 'data/stout/zn/zn_19/zn_19.coll': U data/stout/zn/zn_19/zn_19.coll --- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.coll': U data/stout/zn/zn_19/zn_19.coll --- Recording mergeinfo for merge of r2 through r11144 into 'data/stout/zn/zn_19/zn_19.nrg': U data/stout/zn/zn_19/zn_19.nrg --- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.nrg': U data/stout/zn/zn_19/zn_19.nrg --- Recording mergeinfo for merge of r2 through r11144 into 'data/stout/zn/zn_19/zn_19.tp': U data/stout/zn/zn_19/zn_19.tp --- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.tp': U data/stout/zn/zn_19/zn_19.tp --- Recording mergeinfo for merge of r2 through r11144 into 'source': U source --- Recording mergeinfo for merge of r2 through r11144 into 'tsuite': U tsuite --- Recording mergeinfo for merge of r2 through r11144 into 'tsuite/auto': U tsuite/auto --- Recording mergeinfo for merge of r2 through r11144 into 'tsuite/auto/chianti_all_cool.dat': U tsuite/auto/chianti_all_cool.dat --- Recording mergeinfo for merge of r2 through r11144 into 'tsuite/auto/chianti_all_cool.in': U tsuite/auto/chianti_all_cool.in svn merge ^/trunk . --- Merging r11145 through r11342 into '.': Udata/chianti/masterlist/CloudyChianti.ini G data/lamda/masterlist/Lamda.ini Udata/stout/c/c_3/c_3.coll [ snip... ] C data/stout/zn/zn_19/zn_19.coll C data/stout/zn/zn_19/zn_19.nrg C data/stout/zn/zn_19/zn_19.tp [ snip... ] G tsuite G . --- Recording mergeinfo for merge of r11145 through r11342 into '.': G . --- Recording mergeinfo for merge of r11145 through r11342 into 'data/lamda/masterlist/Lamda.ini': G data/lamda/masterlist/Lamda.ini --- Recording mergeinfo for merge of r11145 through r11342 into 'source': G source --- Recording mergeinfo for merge of r11145 through r11342 into 'tsuite': G tsuite --- Recording mergeinfo for merge of r11145 through r11342 into 'tsuite/auto': G tsuite/auto --- Recording mergeinfo for merge of r11145 through r11342 into 'tsuite/auto/chianti_all_cool.dat': G tsuite/auto/chianti_all_cool.dat --- Recording mergeinfo for merge of r11145 through r11342 into 'tsuite/auto/chianti_all_cool.in': G tsuite/auto/chianti_all_cool.in Summary of conflicts: Property conflicts: 3 Conflict for property 'svn:mergeinfo' discovered on 'data/stout/zn/zn_19/zn_19.coll'. local delete, incoming edit upon merge Select: (p) postpone, (mf) my version, (tf) their version, (dc) display conflict, (e) edit property, (q) quit resolution, (h) help: Here I hit ^C again. So this starts promising enough, but then I am faced with a conflict in the svn:mer
History split after server-side mkdir/mv
I have a repository I had made in a pinch, without any directory
structure, just adding files to the root.
When the time came to add some method to the madness, I created
the 3 canonical directories, then moved (server-side) all files to
'trunk/'. Now, when I issue `svn log' in my freshly checked-out
working copy, I face the following situation:
* 'trunk/' only remembers revisions since when it was created;
* the single files within 'trunk/' remember and show their full
history;
* when I `cd' to the working copy's "root" ('trunk/..') I see
everything: from 1 to HEAD, including all changes to 'trunk/'.
Now, since no history was lost, this is not a real problem. I'd just
like, for 'trunk/' (i.e.: when I'm in 'trunk/' and issue `svn log') to
see everything back to revision 1. So I guess the question is: is there
a way to tell 'trunk/' that it also "owns" the repository root history
up to its birth?
Thanks for your comments,
DN
Subversion Exception - cleanup
Hi there, Firstly, I am not subscribed to this mailing list so would appreciate being explicitly CC'd in any responses. :-) When I attempted to update my repository, I received the following update: Error: The working copy database at 'D:\Work\SVN\trunk' is corrupt. Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout. When I attempted a cleanup, I received the following message: --- 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.9.4\ext\subversion\subversion\libsvn_client\cleanup.c' line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) --- OK --- --- TortoiseSVN --- Cleanup failed to process the following paths: D:\Work\SVN\trunk The working copy database at 'D:\Work\SVN\trunk' is corrupt. Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout. --- OK --- My version information is: TortoiseSVN 1.9.4, Build 27285 - 64 Bit , 2016/04/24 13:59:58 Subversion 1.9.4, -release apr 1.5.2 apr-util 1.5.4 serf 1.3.8 OpenSSL 1.0.2g 1 Mar 2016 zlib 1.2.8 SQLite 3.12.1 I am running Windows 10 v1511 (OS Build 10586.601). Our SVN server (VisualSVN Server) is running SVN 1.7.6 (r1370777) I did try to search the archives for similar problems but received a 403 from Google when I attempted it. If you require any further information, please let me know directly. Kind regards, Dan Atkinson
Re: History split after server-side mkdir/mv
On 10/27/16 7:04 AM, Dario Niedermann wrote:
I have a repository I had made in a pinch, without any directory
structure, just adding files to the root.
When the time came to add some method to the madness, I created
the 3 canonical directories, then moved (server-side) all files to
'trunk/'. Now, when I issue `svn log' in my freshly checked-out
working copy, I face the following situation:
* 'trunk/' only remembers revisions since when it was created;
I think your example will be easier to follow if you provide more
concrete details, such as the specific log commands you're issuing.
However, without further information, it sounds like Subversion is
functioning as designed. Namely, that in Subversion, a folder has
history just like a file. So if you ask for the history of trunk, you
can only find out the history of the folder back to its birth.
* the single files within 'trunk/' remember and show their full
history;
* when I `cd' to the working copy's "root" ('trunk/..') I see
everything: from 1 to HEAD, including all changes to 'trunk/'.
Now, since no history was lost, this is not a real problem. I'd just
like, for 'trunk/' (i.e.: when I'm in 'trunk/' and issue `svn log') to
see everything back to revision 1. So I guess the question is: is there
a way to tell 'trunk/' that it also "owns" the repository root history
up to its birth?
I don't believe there's any good way to do what you want without
recreating the history of your repository. You might be able to achieve
what you want by doing an svnadmin dump & load, where you load to a
sub-directory trunk", then relocate everything buried a level down
(trunk/trunk/...) back into the top-level trunk folder.
Eric.
Thanks for your comments,
DN
Re: Subversion Exception - cleanup
On 10/27/2016 16:36, Dan Atkinson wrote: > Hi there, > > Firstly, I am not subscribed to this mailing list so would appreciate > being explicitly CC'd in any responses. :-) > > When I attempted to update my repository, I received the following update: > > Error: The working copy database at 'D:\Work\SVN\trunk' is corrupt. > Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh > checkout. > > When I attempted a cleanup, I received the following message: > > --- > 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.9.4\ext\subversion\subversion\libsvn_client\cleanup.c' > line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) > --- > OK > --- > > > --- > TortoiseSVN > --- > Cleanup failed to process the following paths: > D:\Work\SVN\trunk > The working copy database at 'D:\Work\SVN\trunk' is corrupt. > Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout. > --- > OK > --- > > My version information is: > TortoiseSVN 1.9.4, Build 27285 - 64 Bit , 2016/04/24 13:59:58 > Subversion 1.9.4, -release > apr 1.5.2 > apr-util 1.5.4 > serf 1.3.8 > OpenSSL 1.0.2g 1 Mar 2016 > zlib 1.2.8 > SQLite 3.12.1 > > I am running Windows 10 v1511 (OS Build 10586.601). > > Our SVN server (VisualSVN Server) is running SVN 1.7.6 (r1370777) > > I did try to search the archives for similar problems but received a > 403 from Google when I attempted it. > > If you require any further information, please let me know directly. > > Kind regards, Dan Atkinson In case of a WC DB corruption I'd say your best bet is to do a fresh checkout and copy over locally modified files from the old working copy to the new one. You can also try to debug/troubleshoot the database corruption and try to repair the database (sqlite3 -> pragma integrity_check) but unless you have a reason to try to save your working copy, there's little point to do so, IMO. Although I doubt it's related to the corruption you ran into: Your VisualSVN Server is quite outdated. I assume you are running Visual SVN Server 2.5.6. I'd certainly suggest you to upgrade your server to 2.5.26 at least (which will bring SVN up to 1.7.21). The upgrade should be as simple as clicking through the installer. If possible, you'd even upgrade to a later one which will bring SVN up to 1.8 or 1.9 (currently VisualSVN Server 3.5.6 is the recommended version). Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
