Subversion Exception!
Was checking out a branch of a repository through a VPN. http://subversion.apache.org/mailing-lists.html --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_ra_serf\util.c' line 1649: internal malfunction --- OK ---
Reverting an ADD status file after an update tree conflict deletes the file
Perform the following steps... 1.Edit a file in a working copy 2.Delete that file in the repository (with the repo browser) 3.Update your working copy 4.Edit the tree conflict and specify "keep working copy" 5.The edited file now shows as an add 6.Revert the working copy Observed: The file with the add status is deleted. Expected: The "add" is removed and the file remains. Basically this is the behavior you get when you revert a file that you just added. I would expect reverting an added file to do the same thing whether the file was marked as add from an update or from just adding it. --- I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra? BOb
RE: Reverting an ADD status file after an update tree conflict deletes the file
Hi, The behavior you see is consistent with reverting a copied file. When the tree conflict is added your local modification of the modified file was changed into a local copy of the file that used to be there. Local additions (with no prior history) are kept on revert, but copies are not. The original reason for this is that you still have the file in the repositories history (in case of a copy), while you don't have files with no prior history. This has the nice side effect that you can revert a ^C'ed merge. If we would keep files that were copied you would have to manually delete the files that were added during the merge. Bert From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: maandag 14 oktober 2013 16:29 To: users@subversion.apache.org Subject: Reverting an ADD status file after an update tree conflict deletes the file Perform the following steps. 1.Edit a file in a working copy 2.Delete that file in the repository (with the repo browser) 3.Update your working copy 4.Edit the tree conflict and specify "keep working copy" 5.The edited file now shows as an add 6.Revert the working copy Observed: The file with the add status is deleted. Expected: The "add" is removed and the file remains. Basically this is the behavior you get when you revert a file that you just added. I would expect reverting an added file to do the same thing whether the file was marked as add from an update or from just adding it. --- I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra? BOb
RE: Reverting an ADD status file after an update tree conflict deletes the file
Bert, But, this isn't a merge it is an update. If I revert the add I lose all the changes I made in step 1 of my steps below. I might have made a few hundred changes. Granted, I probably shouldn't do the revert without copying the file off somewhere... but those local modifications I made are NOWHERE in this case and can't be recovered if my local copy of the file is deleted. BOb From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Monday, October 14, 2013 3:03 PM To: Bob Archer; users@subversion.apache.org Subject: RE: Reverting an ADD status file after an update tree conflict deletes the file Hi, The behavior you see is consistent with reverting a copied file. When the tree conflict is added your local modification of the modified file was changed into a local copy of the file that used to be there. Local additions (with no prior history) are kept on revert, but copies are not. The original reason for this is that you still have the file in the repositories history (in case of a copy), while you don't have files with no prior history. This has the nice side effect that you can revert a ^C'ed merge. If we would keep files that were copied you would have to manually delete the files that were added during the merge. Bert From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: maandag 14 oktober 2013 16:29 To: users@subversion.apache.org Subject: Reverting an ADD status file after an update tree conflict deletes the file Perform the following steps... 1.Edit a file in a working copy 2.Delete that file in the repository (with the repo browser) 3.Update your working copy 4.Edit the tree conflict and specify "keep working copy" 5.The edited file now shows as an add 6.Revert the working copy Observed: The file with the add status is deleted. Expected: The "add" is removed and the file remains. Basically this is the behavior you get when you revert a file that you just added. I would expect reverting an added file to do the same thing whether the file was marked as add from an update or from just adding it. --- I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra? BOb
Re: Reverting an ADD status file after an update tree conflict deletes the file
On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer wrote: > Bert, > > > > But, this isn’t a merge it is an update. If I revert the add I lose all the > changes I made in step 1 of my steps below. I might have made a few hundred > changes. Granted, I probably shouldn’t do the revert without copying the > file off somewhere… but those local modifications I made are NOWHERE in this > case and can’t be recovered if my local copy of the file is deleted. > But, but ... isn't 'revert' always a lossy operation? If you revert a locally modified file you also lose your local modifications. OK, if you revert a normal 'add', svn will keep the local file. But as Bert said, if you revert an 'add with history' (A +), which seems to be the case here, svn will just throw away whatever is there, exactly like when you revert a Modified file. There is no "revert only the add, but keep the local mods" operation. -- Johan
RE: Reverting an ADD status file after an update tree conflict deletes the file
> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer > wrote: > > Bert, > > > > > > > > But, this isn't a merge it is an update. If I revert the add I lose > > all the changes I made in step 1 of my steps below. I might have made > > a few hundred changes. Granted, I probably shouldn't do the revert > > without copying the file off somewhere... but those local modifications > > I made are NOWHERE in this case and can't be recovered if my local copy of > the file is deleted. > > > > But, but ... isn't 'revert' always a lossy operation? If you revert a locally > modified file you also lose your local modifications. But, but, shouldn't then a revert, revert back to the pristine of my working copy, which is the local file without my modifications? I'm not even seeing that, which would somewhat make sense in my head. > > OK, if you revert a normal 'add', svn will keep the local file. But as Bert > said, if > you revert an 'add with history' (A +), which seems to be the case here, svn > will just throw away whatever is there, exactly like when you revert a > Modified file. > > There is no "revert only the add, but keep the local mods" operation. Ok, but bottom line... subversion has TRASHED my local changes. This was really surprised me, and in a bad way. Granted, I only found this in a test and didn't actually lose important modifications. BOb
Re: svn 1.8.3 on windows often crashes
W dniu 2013-10-04 15:04, Ivan Zhakov pisze: On 4 October 2013 17:00, Karol Szkudlarek wrote: W dniu 2013-10-04 14:50, Ivan Zhakov pisze: On 4 October 2013 16:44, Ivan Zhakov wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Well, yes it looks like exactly my problem. Thanks for info about. When the 1.8.4 will be released? Now its very annoying crash. I do 'svn log' very often. :-) There is no specific schedule for patch releases. Usually they come not less often than every month and if important fixes are waiting for release. Subversion 1.8.3 was released 29 August 2013. Hello again Ivan, Now we have 14 of October (so we have roughly more then 1 month from 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. Please tell me ss it possible to back to 1.7.x series or not?! Or somebody from subversion release managers could answer me my question about when will be 1.8.4 released with fix for #4425?! Regards, Karol Szkudlarek -- Karol Szkudlarek Head Of Software Development DCIO Mikronika, HQ Poznan Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Re: Reverting an ADD status file after an update tree conflict deletes the file
On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer wrote: >> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer >> wrote: >> > Bert, >> > >> > >> > >> > But, this isn't a merge it is an update. If I revert the add I lose >> > all the changes I made in step 1 of my steps below. I might have made >> > a few hundred changes. Granted, I probably shouldn't do the revert >> > without copying the file off somewhere... but those local modifications >> > I made are NOWHERE in this case and can't be recovered if my local copy of >> the file is deleted. >> > >> >> But, but ... isn't 'revert' always a lossy operation? If you revert a locally >> modified file you also lose your local modifications. > > But, but, shouldn't then a revert, revert back to the pristine of my working > copy, which is the local file without my modifications? I'm not even seeing > that, which would somewhat make sense in my head. That's indeed pretty strange. I didn't realize that. But even then you would have lost your local changes, no? > >> >> OK, if you revert a normal 'add', svn will keep the local file. But as Bert >> said, if >> you revert an 'add with history' (A +), which seems to be the case here, svn >> will just throw away whatever is there, exactly like when you revert a >> Modified file. >> >> There is no "revert only the add, but keep the local mods" operation. > > Ok, but bottom line... subversion has TRASHED my local changes. This was > really surprised me, and in a bad way. Granted, I only found this in a test > and didn't actually lose important modifications. > You asked it to trash you local changes. That's precisely what revert is for. Ok, I think the underlying problem is that svn currently does a lousy job at helping users resolve tree conflicts. You're really on your own, and have to improvise. Perhaps it's not even possible to resolve this kind of tree conflict with standard commands (without moving the modified file aside, and moving it back etc). So I can perfectly imagine that you get misled into trying 'revert' to get out of the nasty situation. All I can suggest at this time is: never revert something if it still contains uncommitted changes. If you're unsure what will happen, make a backup copy of your local mods first. -- Johan
Re: Reverting an ADD status file after an update tree conflict deletes the file
On 14.10.2013 21:20, Johan Corveleyn wrote: > On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer wrote: >> Bert, >> >> >> >> But, this isn’t a merge it is an update. If I revert the add I lose all the >> changes I made in step 1 of my steps below. I might have made a few hundred >> changes. Granted, I probably shouldn’t do the revert without copying the >> file off somewhere… but those local modifications I made are NOWHERE in this >> case and can’t be recovered if my local copy of the file is deleted. >> > But, but ... isn't 'revert' always a lossy operation? If you revert a > locally modified file you also lose your local modifications. > > OK, if you revert a normal 'add', svn will keep the local file. But as > Bert said, if you revert an 'add with history' (A +), I agree with Bob that this is not good behaviour. It's not a local add, it's "local edit, incoming delete upon update". It may have been resolved to an "add with history" but the "history" in this case is just a previous version of the same file; effectively, the file was resurrected. Throwing away local modifications like this is not nice. That said, it's not exactly a bug, either. The only reasonable solution I can think of is to revert to the exact state before the update, which implies that we'd have to remember that state, local mods and all. In other words, we'd have to implement working copy checkpoints, a.k.a. local commits. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn 1.8.3 on windows often crashes
On 14.10.2013 21:29, Karol Szkudlarek wrote: > W dniu 2013-10-04 15:04, Ivan Zhakov pisze: >> On 4 October 2013 17:00, Karol Szkudlarek >> wrote: >>> W dniu 2013-10-04 14:50, Ivan Zhakov pisze: >>> On 4 October 2013 16:44, Ivan Zhakov wrote: >> I'm trying to use the latest 1.8.3 64-bit version of svn client: >> >> CollabNetSubversion-client-1.8.3-1-x64.exe >> >> but several times crashes. In attachement are log and dmp. > Hi, > > The attached dumps and logs doesn't have debug symbols included, this > we're unable to investigate the issue. I recommend you contact > company > produced this binaries (CollabNet) or try to reproduce problem with > other Subversion binaries distribution and contact them. > Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 >>> Well, yes it looks like exactly my problem. Thanks for info about. >>> When the >>> 1.8.4 will be released? >>> Now its very annoying crash. I do 'svn log' very often. :-) >> There is no specific schedule for patch releases. Usually they come >> not less often than every month and if important fixes are waiting for >> release. Subversion 1.8.3 was released 29 August 2013. >> > Hello again Ivan, > > Now we have 14 of October (so we have roughly more then 1 month from > 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. > Please tell me ss it possible to back to 1.7.x series or not?! > Or somebody from subversion release managers could answer me my > question about when will be 1.8.4 released with fix for #4425?! You're not likely to get free help by shouting at people. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: Reverting an ADD status file after an update tree conflict deletes the file
> On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer > wrote: > >> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer > >> wrote: > >> > Bert, > >> > > >> > > >> > > >> > But, this isn't a merge it is an update. If I revert the add I lose > >> > all the changes I made in step 1 of my steps below. I might have > >> > made a few hundred changes. Granted, I probably shouldn't do the > >> > revert without copying the file off somewhere... but those local > >> > modifications I made are NOWHERE in this case and can't be > >> > recovered if my local copy of > >> the file is deleted. > >> > > >> > >> But, but ... isn't 'revert' always a lossy operation? If you revert a > >> locally modified file you also lose your local modifications. > > > > But, but, shouldn't then a revert, revert back to the pristine of my working > copy, which is the local file without my modifications? I'm not even seeing > that, which would somewhat make sense in my head. > > That's indeed pretty strange. I didn't realize that. But even then you would > have lost your local changes, no? Indeed. But, then I would have slapped my head and said, "Self (that's what I call myself), it just did what you told it to do." ;) Once again though, to repeat, I am 100% used to when reverting an ADD the file isn't removed. My tiny brain doesn't know ADD from ADD with History from a black hole. > >> OK, if you revert a normal 'add', svn will keep the local file. But > >> as Bert said, if you revert an 'add with history' (A +), which seems > >> to be the case here, svn will just throw away whatever is there, > >> exactly like when you revert a Modified file. > >> > >> There is no "revert only the add, but keep the local mods" operation. > > > > Ok, but bottom line... subversion has TRASHED my local changes. This was > really surprised me, and in a bad way. Granted, I only found this in a test > and > didn't actually lose important modifications. > > > > You asked it to trash you local changes. That's precisely what revert is for. > > Ok, I think the underlying problem is that svn currently does a lousy job at > helping users resolve tree conflicts. You're really on your own, and have to > improvise. Perhaps it's not even possible to resolve this kind of tree > conflict > with standard commands (without moving the modified file aside, and > moving it back etc). So I can perfectly imagine that you get misled into > trying > 'revert' to get out of the nasty situation. All I can suggest at this time > is: never > revert something if it still contains uncommitted changes. If you're unsure > what will happen, make a backup copy of your local mods first. Perhaps. If there were a true life issue I might have said... no, that file was deleted for a reason, so I don't want to re-add it, I want to take my code changes and apply them in the correct new place. So, I'll just revert this "ADD" (which I know from past experience will just keep my local file) and find the correct place to apply these changes... N... that algorithm I spend 4 hours on is gone... DAMN YOU NEWMAN!!! (I mean subversion!) BOb
RE: svn 1.8.3 on windows often crashes
> W dniu 2013-10-04 15:04, Ivan Zhakov pisze: > > On 4 October 2013 17:00, Karol Szkudlarek > wrote: > >> W dniu 2013-10-04 14:50, Ivan Zhakov pisze: > >> > >>> On 4 October 2013 16:44, Ivan Zhakov wrote: > > I'm trying to use the latest 1.8.3 64-bit version of svn client: > > > > CollabNetSubversion-client-1.8.3-1-x64.exe > > > > but several times crashes. In attachement are log and dmp. > Hi, > > The attached dumps and logs doesn't have debug symbols included, > this we're unable to investigate the issue. I recommend you contact > company produced this binaries (CollabNet) or try to reproduce > problem with other Subversion binaries distribution and contact them. > > >>> Well, I checked logs more carefully and it seems like issue #4425 > >>> [1] which is fixed in r1522892 and proposed for backport to > >>> Subversion 1.8.4. > >>> > >>> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 > >>> > >> Well, yes it looks like exactly my problem. Thanks for info about. > >> When the > >> 1.8.4 will be released? > >> Now its very annoying crash. I do 'svn log' very often. :-) > > There is no specific schedule for patch releases. Usually they come > > not less often than every month and if important fixes are waiting for > > release. Subversion 1.8.3 was released 29 August 2013. > > > Hello again Ivan, > > Now we have 14 of October (so we have roughly more then 1 month from > 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. > Please tell me ss it possible to back to 1.7.x series or not?! Of course it is. Of course, there is no way to downgrade a working copy that I am aware of, so you would have to do a clean checkout. BOb > Or somebody from subversion release managers could answer me my > question about when will be 1.8.4 released with fix for #4425?! > > Regards, Karol Szkudlarek > > > -- > Karol Szkudlarek > Head Of Software Development > DCIO > > Mikronika, HQ Poznan > > Please consider your environmental responsibility. > Before printing this e-mail message, ask yourself whether you really need a > hard copy.
subversion changes file permissions on commit
Hi,
I store OS images in svn, so I need to record file permissions and
ownership. For this, I use properties.
But svn changes real file permissions:
# ls -l fstab
-rw-r--r-- 1 root wheel 230 Oct 22 2011 fstab
# svn pg file:permissions fstab
mode=33188 user=(0) group=(0)
# chmod 600 fstab
# svn ps file:permissions 'mode=33152 user=(0) group=(0)' fstab
property 'file:permissions' set on 'fstab'
# ls -l fstab
-rw--- 1 root wheel 230 Oct 22 2011 fstab
# svn commit -m test fstab
Sendingfstab
Committed revision 29956.
# ls -l fstab
-rw-r--r-- 1 root wheel 230 Oct 22 2011 fstab
Why svn works like this and what can I do to disable/work around this
feature?
BTW, this is the trace where the chmod happens:
56718 svn CALL unlink(0x804c93ba0)
56718 svn NAMI "/tmp/svn-e21669fe.tmp"
56718 svn RET unlink 0
56718 svn CALL fstat(0x7,0x7fffcce0)
56718 svn STRU struct stat {dev=795533270, ino=6620,
mode=-rw--- , nlink=1, uid=0, gid=0, rdev=4294967295,
atime=1319311412.576898307, stime=1319311412.576898307,
ctime=1381814933.936353362, birthtime=1319311412.576898307, size=230,
blksize=4096, blocks=2, flags=0x0 }
56718 svn RET fstat 0
56718 svn CALL close(0x7)
56718 svn RET close 0
56718 svn CALL
chmod(0x804c927c8,0x1a4)
56718 svn NAMI "/data/bootsrv/conf/test/etc/fstab"
56718 svn RET chmod 0
# svn --version
svn, version 1.8.3 (r1516576)
# apr-1-config --version
1.4.8
ps: please keep me on CC.
