Re: branching WC folder fails with files marked as deleted
Hello Daniel, hello Stefan
Sorry for the empty email. Dont know what happened to the web email.
I guess I found the issue and implemented the following feature in our
MSSCCI wrapper.
If you can confirm that, when I find a "deleted" line in the .svn/entries
file to a WC controlled file as shown below, then the file was only deleted
in the WC and is marked for deletion in the repo which will be done with
the next commit. Is this the exact meaning of "deleted" the the WC control
area entries file? And there is no other meaning?
c1cf5a64-afc7-45b3-963c-f8ce2ed2cecf.mtx
file
124877
< : >
deleted
Feature justification:
When a file is added to the repo, sync'd
(checked out/updated) to the working copy (by MTPE/MWT/MSSCCI),
later the same file is deleted from the repo and the working copy
sync'd (by MTPE/MWT/MSSCCI) again, this file is NOT 'updated'
(svn up file) which with SVN would remove the file from the working
copy but instead is (falsely) 'deleted' (svn del file) which removes
the working copy file and marks this file as scheduled to be deleted
in the working copies control area (.svn/entries).
Feature:
A 'SccGet' immediately following a 'SccPopulateList' where the
folders (SccPopList) and the file folders (SccGet) do match between
the two calls, will trigger a user dialogue asking whether to
update the folders instead of the file list passed to SccGet.
The feature can be controlled by setting the list size either
to <= 0 to disabled, or to > 0 to enable and configure the max.
file / folder list length in the dialog.
Use case:
MTPE/MWT sync.
>
> Original-Nachricht
> Datum: Thu, 10 Jan 2013 00:33:38 +0200
> Von: Daniel Shahaf
> An: Roman Kellner , users@subversion.apache.org
> Betreff: Re: branching WC folder fails with files marked as deleted
>
> Stefan Sperling wrote on Wed, Jan 09, 2013 at 14:21:06 +0100:
> > On Wed, Jan 09, 2013 at 02:02:32PM +0100, Roman Kellner wrote:
> > > - Now the user-A needs to branch his WC and gets the following error
> > > message on commit
> > > (the file shown in the error message is the one that was created and
> later
> > > deleted):
> >
> > Please do not attach images when posting to a mailing list.
> > Instead, copy/paste the error message into your email in plain text.
> >
> > > I would consider this a bug. Why does the client not simply ignore
> deleted
> > > marked file entries?
> >
> > Subversion represents renames as a copy and a delete operation.
> >
> > Subversion does not allow you to commit deletions of outdated items,
> > because this would prevent some tree conflicts from being detected.
>
> I don't think one needs to understand tree conflicts to understand why
> deleting out of date files is prevented. You can't delete a file that
> has been committed to after you checked it out for the same reason you
> can't modify such a file: because allowing you to go through would lead
> to silently discarding the changes were done made in the newer revision
> that your wc doesn't have.
>
> ('svn cp foo@oldrev bar' excepted)
>
Re: branching WC folder fails with files marked as deleted
"Roman Kellner" writes: > If you can confirm that, when I find a "deleted" line in the .svn/entries > file to a WC controlled file as shown below, then the file was only deleted > in the WC and is marked for deletion in the repo which will be done with > the next commit. Is this the exact meaning of "deleted" the the WC control > area entries file? And there is no other meaning? 'deleted' in the entries file represents svn_wc_entry_t.deleted=TRUE and is different from 'delete' which represents svn_wc_entry_t.schedule=svn_wc_schedule_delete 'delete' is when a file in the WC is marked for deletion at the next commit. 'deleted' is when an entry is not present in the working copy but would be expected given the revision of the parent. So after svn rm f f is 'delete' and after svn ci f is 'deleted' and after svn up f is no longer in .svn/entries. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: branching WC folder fails with files marked as deleted
On Fri, Jan 11, 2013 at 09:01:56AM +0100, Roman Kellner wrote: > Hello Daniel, hello Stefan > > Sorry for the empty email. Dont know what happened to the web email. > > I guess I found the issue and implemented the following feature in our > MSSCCI wrapper. > > If you can confirm that, when I find a "deleted" line in the .svn/entries > file to a WC controlled file as shown below, then the file was only deleted > in the WC and is marked for deletion in the repo which will be done with > the next commit. Is this the exact meaning of "deleted" the the WC control > area entries file? And there is no other meaning? We've long moved past the entries file format. We aren't even fixing bugs in the 1.6 WC implementation anymore (unless they're security or data corruption fixes). The current Subversion 1.7 working copy works in entirely different ways, and we will stop supporting 1.6 entirely when 1.8 is released. I would not recommened you rely on the entries file format in any way in your script/product. Use the svn status --xml comand or the Subversion APIs instead, which can be accessed from several programming languages (see here for API docs: http://subversion.apache.org/docs/#api) FWIW here's the documentation of the 'deleted' field, from the file https://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_wc/README deleted: A boolean: true if this entry is deleted in its revision but exists in its parent's revision. This is necessary because updates are not atomic: different bits of a working copy can be updated to different revisions at different times, and it's possible that this entry may be updated to a more recent revision (R) than its parent's revision (P). If this entry is deleted in R, and the parent is trying to report its own state (based on P) to the repository, the parent cannot simply claim to be at P; the parent must also indicate that this particular entry is deleted because it is at R. So this flag is used in the 1.6 working copy to represent mixed-revision working copies, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs > > c1cf5a64-afc7-45b3-963c-f8ce2ed2cecf.mtx > file > 124877 > > < : > > > deleted > > > Feature justification: > When a file is added to the repo, sync'd > (checked out/updated) to the working copy (by MTPE/MWT/MSSCCI), What is MTPE/MWT/MSSCCI? Please provide some context or a least a reference. I'm afraid I don't really understand what you are talking about. It seems to be some tool. What is this tool doing and why is it managing a Subversion working copy? And why would it want to fiddle with Subversion's meta data in .svn directories? > later the same file is deleted from the repo and the working copy > sync'd (by MTPE/MWT/MSSCCI) again, this file is NOT 'updated' > (svn up file) which with SVN would remove the file from the working > copy but instead is (falsely) 'deleted' (svn del file) which removes > the working copy file and marks this file as scheduled to be deleted > in the working copies control area (.svn/entries). This is what mixed-revisions do. You need to update the parent folder of the file as well to get rid of the 'deleted' flag. However the file should disappear from the working copy (i.e. it should disappear from disk). If it doesn't, then please try Subversion 1.7 to see if the problem has been fixed there. > > Feature: > A 'SccGet' immediately following a 'SccPopulateList' where the > folders (SccPopList) and the file folders (SccGet) do match between > the two calls, will trigger a user dialogue asking whether to > update the folders instead of the file list passed to SccGet. > The feature can be controlled by setting the list size either > to <= 0 to disabled, or to > 0 to enable and configure the max. > file / folder list length in the dialog. In what way does this part relate to the above? Please explain more. What problem are you trying to solve? > > Use case: > MTPE/MWT sync.
RE: branching WC folder fails with files marked as deleted
This issue sounds like a combination of issues #2763 and #3569.
The ‘svn up --depth empty’ in 1.6 triggers issue #3569:
http://subversion.tigris.org/issues/show_bug.cgi?id=3569 ‘svn update --depth
allows making a working copy incomplete’
While #2763 handles some similar cases in copies:
http://subversion.tigris.org/issues/show_bug.cgi?id=2763 ‘del -> ci -> cp =
missing directory?’
Both issues were fixed for 1.7 and are very hard to fix for 1.6 and earlier, as
the fix for both relies on the additional layers in WC-NG.
The easy fixes you might try break in other cases, as the data to do the right
thing is just not stored in the working copy in 1.6.
Bert
From: Roman Kellner [mailto:muzu...@gmx.net]
Sent: vrijdag 11 januari 2013 09:02
To: Daniel Shahaf; users@subversion.apache.org
Subject: Re: branching WC folder fails with files marked as deleted
Hello Daniel, hello Stefan
Sorry for the empty email. Dont know what happened to the web email.
I guess I found the issue and implemented the following feature in our MSSCCI
wrapper.
If you can confirm that, when I find a "deleted" line in the .svn/entries file
to a WC controlled file as shown below, then the file was only deleted in the
WC and is marked for deletion in the repo which will be done with the next
commit. Is this the exact meaning of "deleted" the the WC control area entries
file? And there is no other meaning?
c1cf5a64-afc7-45b3-963c-f8ce2ed2cecf.mtx
file
124877
< : >
deleted
Feature justification:
When a file is added to the repo, sync'd
(checked out/updated) to the working copy (by MTPE/MWT/MSSCCI),
later the same file is deleted from the repo and the working copy
sync'd (by MTPE/MWT/MSSCCI) again, this file is NOT 'updated'
(svn up file) which with SVN would remove the file from the working
copy but instead is (falsely) 'deleted' (svn del file) which removes
the working copy file and marks this file as scheduled to be deleted
in the working copies control area (.svn/entries).
Feature:
A 'SccGet' immediately following a 'SccPopulateList' where the
folders (SccPopList) and the file folders (SccGet) do match between
the two calls, will trigger a user dialogue asking whether to
update the folders instead of the file list passed to SccGet.
The feature can be controlled by setting the list size either
to <= 0 to disabled, or to > 0 to enable and configure the max.
file / folder list length in the dialog.
Use case:
MTPE/MWT sync.
Original-Nachricht
Datum: Thu, 10 Jan 2013 00:33:38 +0200
Von: Daniel Shahaf
An: Roman Kellner , users@subversion.apache.org
Betreff: Re: branching WC folder fails with files marked as deleted
Stefan Sperling wrote on Wed, Jan 09, 2013 at 14:21:06 +0100:
> On Wed, Jan 09, 2013 at 02:02:32PM +0100, Roman Kellner wrote:
> > - Now the user-A needs to branch his WC and gets the following error
> > message on commit
> > (the file shown in the error message is the one that was created and later
> > deleted):
>
> Please do not attach images when posting to a mailing list.
> Instead, copy/paste the error message into your email in plain text.
>
> > I would consider this a bug. Why does the client not simply ignore deleted
> > marked file entries?
>
> Subversion represents renames as a copy and a delete operation.
>
> Subversion does not allow you to commit deletions of outdated items,
> because this would prevent some tree conflicts from being detected.
I don't think one needs to understand tree conflicts to understand why
deleting out of date files is prevented. You can't delete a file that
has been committed to after you checked it out for the same reason you
can't modify such a file: because allowing you to go through would lead
to silently discarding the changes were done made in the newer revision
that your wc doesn't have.
('svn cp foo@oldrev bar' excepted)
Re: Cant open repository folder
Stefan Sperling wrote on Thu, Jan 10, 2013 at 17:59:50 +0100: > On Tue, Jan 08, 2013 at 06:34:54PM +0530, noufal av wrote: > > how i solve this problem..plzz help me and i waiting for ur solution > > The repository cannot be read because the 'current' file is apparently > empty. This means Subversion has no way of knowing what the latest > revision in the repository is. > > I'd suggest to restore the repository from backup. > > If you don't have a recent backup, please take some time to think > about how you are going to keep recent backups of your repositories > in the future :) > And try to write the number of the current HEAD revision into the > 'current' file. That might fix the repository. 'svnadmin recover' does that.
Truncated file issues
Hi, We're having an issue that has occurred three times in the past two weeks with two different repositories hosted with VisualSVN (version 2.5.8). Upon checkout, we get the following message: REPORT of '/svn//!svn/me': Could not read chunk size: Secure connection truncated Apache logs show: [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure occurred while driving the update report editor [500, #70014] [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read file 'E:\\db\\revs\\0\\135': End of file found [500, #70014] svnadmin verify returns: * Verified revision 135. svnadmin: E070014: Can't read file 'E:\\\db\revs\0\135': End of file found This is a major issue for us as we're actively developing against these projects and having to recommit over and over again. Currently resolving the issue by creating a dump to the revision prior to the truncation and then loading into a new repository, but this is costing development time. Thanks for advance for your help. Paul
Re: Truncated file issues
Guten Tag Paul E, am Donnerstag, 10. Januar 2013 um 21:11 schrieben Sie: > This is a major issue for us as we're actively developing against > these projects and having to recommit over and over again. Currently > resolving the issue by creating a dump to the revision prior to the > truncation and then loading into a new repository, but this is costing > development time. Something is corrupting your repository, but your on your own to find the problem. From what I've read it's most likely a hardware or OS problem, for example your filesystem may be corrupted. I had similar issues some years ago with a virtualized Windows where for some reason the filesystem broke two times in one weak and the only solution was to create a new file system and restore into this from backup. Have a look at your event viewer, do checkdisk, maybe even memory tests, you can even try to monitor disk access with Process Monitor form Sysinternals to see if something occurs. But first of all I would implement a good backup process, e.g. using svnsync and hooks or something similar, as it doesn't sound you are prepared for loss of revision files. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Truncated file issues
On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote: > Hi, > > We're having an issue that has occurred three times in the past two weeks > with two different repositories hosted with VisualSVN (version 2.5.8). VisualSVN 2.5.8 is pretty recent. Did this start happening after an upgrade/install of 2.5.8? Have you tried downgrading to 2.5.7 to see if that fixes the issue? VisualSVN 2.5.8 includes Subversion 1.7.8, which has the following change in the FSFS filesystem code: * fix fs_fs to cleanup after failed rep transmission (r1403964, et al) Maybe what you are seeing is a regression introduced with that fix? Please confirm if possible. Thanks! BTW, a similar issue has been reported here: http://svn.haxx.se/users/archive-2013-01/0029.shtml > Upon checkout, we get the following message: > > REPORT of '/svn//!svn/me': Could not read chunk size: Secure > connection truncated > > Apache logs show: > > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure > occurred while driving the update report editor [500, #70014] > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read file > 'E:\\db\\revs\\0\\135': End of file found [500, > #70014] > > svnadmin verify returns: > > * Verified revision 135. > svnadmin: E070014: Can't read file 'E:\\\db\revs\0\135': > End of file found > > This is a major issue for us as we're actively developing against these > projects and having to recommit over and over again. Currently resolving > the issue by creating a dump to the revision prior to the truncation and > then loading into a new repository, but this is costing development time. > > Thanks for advance for your help. > > Paul
--non-interactive seems not to work as expected
Hi, I stumbled upon a misbehavior of the svn client. Providing http basic auth over the --non-interactive option, does not work svn checkout --non-interactive --no-auth-cache --username --password > svn: E170001: Unable to connect to a repository at URL 'http://xxx' > svn: E170001: OPTIONS of 'http://xxx': authorization failed: Could not > authenticate to server: rejected Basic challenge (http://xxx) > > v1:tmp zeph$ svn --version > svn, version 1.7.8 (r1419691) >compiled Jan 3 2013, 13:26:29 > > on OsX 10.7.5 with Homebrew either with… > svn: OPTIONS of 'http://xxx': authorization failed: Could not authenticate to > server: rejected Basic challenge (http://xxx) on an Amazon's linux machine > root@ip-10-48-162-xxx:~# svn --version > ]svn, version 1.6.6 (r40053) >compiled Jun 5 2011, 14:52:04 > root@ip-10-48-162-xxx:~# uname -a > Linux ip-10-48-162-xxx 2.6.32-302-ec2 #6-Ubuntu SMP Sat Feb 6 19:33:14 UTC > 2010 i686 GNU/Linux some other people seem to have experienced the same… - http://serverfault.com/questions/19940/svn-client-authentication-error - http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&viewType=browseAll&dsMessageId=453191 - https://jira.codehaus.org/browse/SONARPLUGINS-2561 Can you confirm it? I'm proceeding in checking out the source code to have a look... regards, -- Guido Serra, Chief Troubleshooter @ Rocket Internet GmbH Skype: zeph1ro | DE: +49 162 2904 629 | JohannisStr.20 10117 Berlin (Office: 4.3.a, east side)
Re: Truncated file issues
Apologies, I failed to mention that I had upgraded VisualSVN Server from 2.5.6 to 2.5.8 after the first repository exhibited corruption. I have not tried VisualSVN 2.5.7. I have looked into potential hardware issues, but am fairly confident that's not the issue. This is fully redundant server with a RAID drive configuration and hardware tests are all checking out. For further specifications, this is a 64-bit Windows 2008 R2 machine. On Fri, Jan 11, 2013 at 11:37 AM, Stefan Sperling wrote: > On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote: > > Hi, > > > > We're having an issue that has occurred three times in the past two weeks > > with two different repositories hosted with VisualSVN (version 2.5.8). > > VisualSVN 2.5.8 is pretty recent. Did this start happening after an > upgrade/install of 2.5.8? Have you tried downgrading to 2.5.7 to see > if that fixes the issue? > > VisualSVN 2.5.8 includes Subversion 1.7.8, which has the following change > in the FSFS filesystem code: > * fix fs_fs to cleanup after failed rep transmission (r1403964, et al) > > Maybe what you are seeing is a regression introduced with that fix? > > Please confirm if possible. Thanks! > > BTW, a similar issue has been reported here: > http://svn.haxx.se/users/archive-2013-01/0029.shtml > > > Upon checkout, we get the following message: > > > > REPORT of '/svn//!svn/me': Could not read chunk size: Secure > > connection truncated > > > > Apache logs show: > > > > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] A failure > > occurred while driving the update report editor [500, #70014] > > [Wed Jan 02 20:59:20 2013] [error] [client xxx.xxx.xxx.xxx] Can't read > file > > 'E:\\db\\revs\\0\\135': End of file found [500, > > #70014] > > > > svnadmin verify returns: > > > > * Verified revision 135. > > svnadmin: E070014: Can't read file > 'E:\\\db\revs\0\135': > > End of file found > > > > This is a major issue for us as we're actively developing against these > > projects and having to recommit over and over again. Currently resolving > > the issue by creating a dump to the revision prior to the truncation and > > then loading into a new repository, but this is costing development time. > > > > Thanks for advance for your help. > > > > Paul >
