Every time I try to check out an "Out Of Date" file, I receive the following error: "Error during file delta checkout". If I delete the file in my working directory, the file now appears to be "missing" in the StarTeam client and I can do a check out without any problems. What is going on?
If you're running 2009R2, make sure "Optimize for slow connections" is turned off under Tools, Personal Options, File. That should prevent your client from requesting deltas.
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.borland.stserver.doc%2Fhtml%2Fhives.htm
As to the root cause of the delta retrieve error, that is probably a MicroFocus support issue. On older versions of StarTeam where deltas were kept (pre-2005), upgrades to certain server versions/patches could raise a similar error. Fixes ranged from cleaning out the cache directory on the server to running custom scripts from Borland to fix broken DB references.
Related
I'm trying to figure out the root cause of a strange TFS error we are seeing in our current instance. It wasn't noticed until after a server move, but I'm not sure if they're directly related, because the error seems to be showing up for check-ins about a week prior to the move, as well as all those following it.
We first noticed the problem when I tried to get latest, and got several errors indicating:
"The downloaded file is corrupt. Please get the file again."
Upon looking into the error, we have noticed that starting as of a single check-in every code update has resulted in files being replaced with the contents of other files, ranging from project files to binary executable files (presumably assembly DLLs), rather than the expected content which is still present on our local development machines.
I don't have admin access to the servers myself, but am looking for ideas on possible causes and/or fixes for our team to investigate.
After weeks of searching, I finally found another mention of this sort of thing happening, along with a solution that appears to have worked.
Clear the Application Tier cache.
MSDN Archived Forums: TFS swapping contents of files
I'm trying to utilize SVNBridge so that my team can use our existing TFS server as our Xcode repository.
SVNBridge appears to be set up correctly on the TFS server, and I can connect to it from Xcode as an SVN repository to grab everything and commit changes.
However, when I have another member of my team update to grab a file I just committed, they receive the following error:
svn: REPORT of '/!svn/bc/36163/-TFS folder structure-': 200 OK (http://-tfs server url-:8081)
The also happens when they update a file, and I then try to update.
We both have full read/write access to the TFS structure.
There is nothing in the SVNBride logs folder on the TFS server.
Any thoughts on the error, or is there a better solution I should use for this?
y0-1, happens all the time for me.
Possible causes are
1) urlscan, check the logs
2) ..svnbridge folders, I usually connect to TFS with native client and delete them, it's a pain cause there are a lot of them usually. After deleting ..svnbridge folders you might want to re-checkout parts of your project where you deleted them and sometimes svnbridge restart is required.
Also svnbridge log usually conatains very usefull info ;)
p.s.
Just realized, that you said that your svnbridge log is clean, that's odd, maybe it is not configured properly(usually folder permissions)
f.e. mine svnbridge log with the similar error on update -
Message : The item 'blah-blah-blah' does not exist at the specified version.
User :
Request : REPORT /!svn/vcc/default HTTP/1.1
We use Nant to automate our builds. Everything was working fine until about a week ago when the rains caused our power to go out and the build server had to be re-booted. Now, we get the following error whenever we attempt a build:
<internalerror>
<type>System.Runtime.InteropServices.COMException</type>
<message><![CDATA[SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.]]></message>
<stacktrace><![CDATA[ at SourceSafeTypeLib.VSSItemClass.Get(String& Local, Int32 iFlags)
at NAnt.Contrib.Tasks.SourceSafe.GetTask.ExecuteTask()]]></stacktrace>
</internalerror>
We ran the Analyze utility on the VSS database and there appears to be plenty of room on the build server, but no luck. Any ideas? I'm at a loss.
My problem was that the current file was empty... I wrote a comment on it and everything worked ok
Ok, here is the resolution. It turns out that somehow, the version of an app.config file that was referenced in the build script was corrupted (all the previous versions, actually), which caused the VSSGet error. Updating the version to the current version fixed the errror.
I had this issue when I tried to migrate a Source Safe database to Subversion, using VSS2SVN.
This error is related to the message
There is a diff chain size mismatch in file '' (bdaaaaaa) at version (versions earlier than that version can no longer be retrieved from the database).
that may be reported by the Source Safe tool analyze.exe.
If you look into the history of the file and try to Get a version that is older than the one reported by analyze.exe, the message of this question is shown.
Microsoft provided hotfix KB927887 for cases where this was caused by XML files toggling BOM inclusion, but I did not try to apply it.
See also Message: SourceSafe was unable to finish writing a file
Ok I have apparently caused a large problem with my companies tortoise svn program, me and the admin are in the process of trying to fix it, but were not having much luck, here is my error message:
Unable to open an ra_local session to URL
Unable to open repository 'file://file/directory/project/folder'
Berkeley DB error for filesystem '//file/directory/db' while opening
'nodes' table:
Invalid argument
bdb: file nodes (meta pgno = 0) has LSN [13005][1627022].
bdb: end of log is [13105][1531127]
bdb: \\file\directory\db\nodes: unexpected file type or format
This error occurs when i attempt to update, similar errors occur when I try to commit, or check out, also.
of course I have changed a couple of things in the error message, like the actuall directories we have here, but that is all I have changed.
the error occurred when I attempted to check something out, it then hung up, and i had to close it, then after this, it has been giving us this error.
Were running it on windows xp and the tortoise version number is 1.5.2
Our Admin tried using the svnadmin to repair the system, and when it told him it was complete it spit up a similar error once again. any one out there in tv land have any ideas what might be the problem here?
The svnadmin command line tool (not bundled with TortoiseSVN) has some subcommands to perform maintenance on the repository. You appear to be using Berkeley DB so you should also read the Berkeley DB Recovery chapter. You can download svn binaries from Slik SVN.
Update: Latest releases of TortoiseSVN already bundle svnadmin and most other useful command-line utilities, thus you no longer need Slik SVN.
I have a fairly large PHP codebase (10k files) that I work with using Eclipse 3.4/PDT 2 on a windows machine, while the files are hosted on a Debian fileserver. I connect via a mapped drive on windows.
Despite having a 1gbit ethernet connection, doing an eclipse project refresh is quite slow. Up to 5 mins. And I am blocked from working while this happens.
This normally wouldn't be such a problem since Eclipse theoretically shouldn't have to do a full refresh very often. However I use the subclipse plugin also which triggers a full refresh each time it completes a switch/update.
My hunch is that the slowest part of the process is eclipse checking the 10k files one by one for changes over samba.
There is a large number of files in the codebase that I would never need to access from eclipse, so I don't need it to check them at all. However I can't figure out how to prevent it from doing so. I have tried marking them 'derived'. This prevents them from being included in the build process etc. But it doesn't seem to speed up the refresh process at all. It seems that Eclipse still checks their changed status.
I've also removed the unneeded folders from PDT's 'build path'. This does speed up the 'building workspace' process but again it doesn't speed up the actual refresh that precedes building (and which is what takes the most time).
Thanks all for your suggestions. Basically, JW was on the right track. Work locally.
To that end, I discovered a plugin called FileSync:
http://andrei.gmxhome.de/filesync/
This automatically copies the changed files to the network share. Works fantastically. I can now do a complete update/switch/refresh from within Eclipse in a couple of seconds.
Do you have to store the files on a share? Maybe you can set up some sort of automatic mirroring, so you work with the files locally, and they get automatically copied to the share. I'm in a similar situation, and I'd hate to give up the speed of editing files on my own machine.
Given it's subversioned, why not have the files locally, and use a post commit hook to update to the latest version on the dev server after every commit? (or have a specific string in the commit log (eg '##DEPLOY##') when you want to update dev, and only run the update when the post commit hook sees this string).
Apart from refresh speed-ups, the advantage of this technique is that you can have broken files that you are working on in eclipse, and the dev server is still ok (albeit with an older version of the code).
The disadvantage is that you have to do a commit to push your saved files onto the dev server.
I solwed this problem by changing "File Transfer Buffer Size" at:
Window->Preferences->Remote Systems-Files
and change "File transfer buffer size"-s Download (KB) and Upload (KB) values to high value, I set it to 1000 kb, by default it is 40 kb
Use offline folder feature in Windows by right-click and select "Make availiable offline".
It could save a lot of time and round trip delay in the file sharing protocol.
The use of svn externals with the revision flag for the non changing stuff might prevent subclipse from refreshing those files on update. Then again it might not. Since you'd have to make some changes to the structure of your subversion repository to get it working, I would suggest you do some simple testing before doing it for real.