csharp1024:

FireFox works on more than just windows, so why would it use directx?

Single source can compile for multiple targets.

Here's a great series of programming articles that covers this, as well as many other good structural issues:

Code on the Cob by Chris Hargrove 
http://www.gamedev.net/reference/list.asp?categoryid=215

Do you have any details about the problem that occurred?

From the sounds of it, you tried to build, it failed, and then you discovered that your source content was missing. Are you sure the missing content didn't cause the build failure in the first place?

What errors were reported by the build?
Did you examine the build log? (Every build logs output in the Output window.)
Were source files removed from the project (as shown in the IDE), or just deleted from disk?

I can certainly understand that under the pressure of trying to submit, you didn't spend a lot of time trying to evaluate what actually happened. However, I'm really, really skeptical that watching a youtube video caused VS to delete your source files. I have no doubt that you watched a video, or that your files were gone, but you haven't really provided any details to link the two, or even to explain why you think VS deleted your files.

Matthew Doucette:

Maybe Jason already said this, but in a nutshell we want something to lock out files the other is working on or has changed.  And then a way to share them.  And to do this almost seamlessly.  Is that asking for too much?! lol

I didn't see that this was answered already, so I'm chiming in here. Up front: I'm a big Subversion fan too. Your argument that "it's only my brother and me, so why would we need this?" doesn't really cut it. I am only one developer, and I'm still using Subversion. At work, we are only three in the time and still, we would be totally lost without SVN. Wouldn't want to miss it! Trust me (and the others): Once you have started using it in earnest, you will never want to go back and you will ask yourself how you could ever have lived without it and why you resisted it so long! Really, believe us! :-)

To answer your question: Yes, that is entirely possible. Although for text based files (like C# source files) you won't want to have this lock out of files where the other is working on, because for such files, it is really totally normal that actually several developers edit the same (text) file, and subversion takes care of the merging:

There is the central SVN repository. It stores all files, ordered into revision. In addion, each developer has his own working copy folder, where he has a copy of all files from the repository. Usually, a developer starts off by "seeding" his working copy with a copy of the latest revision of all files (this is called "Updating" the working copy from the repository). And then he simply starts editing the files in his working copy as much as he wants.
Another developer has his own working copy, also initially "updated"  with the latest revision (the head revision) from the repository. This second developer also edits the files in his own working copy as much as he wants.
Since both developers are editing files in their own working copy folders, there is no conflict between the two.
Then at some point, one of the developers decides, that he is now done with his changes, and that his changes should become part of the main repository. For example when he is done with a task, or maybe simply when he calls it a day (and his files are in a state so that the project is build-able). At that point he "commits" his changes back to the repository. By doing so, the  repository creates a new revision, which contains all the changes that were just committed by this developer.

At some point later, the other developer also decides to check in his files. When he does so, SVN tells him that the revision in the repository is a later one (because of the commit from the first developer) than the revision from which the second developer initially had updated his working copy. So before the second developer can commit his changes, he first has to update his working copy to the latest revision.
By this update, he now gets all the changes that the first developer committed earlier and SVN automatically merges them into his own working copy:
Any changes from the update that are in files that the second developer didn't touch are merged automatically. But even changes from the update that are in files that the second developer did also edit can be merged, as long as those changes are in different lines. For example, if developer A changes a method ABC in file X,  and developer B changes method DEF in the same file X, then these changes are merged automically. Only if both developers have changed the same lines, can the merge not happen automatically. (Although in practice this actually happens not very often.)
In this case, SVN flags this file as conflicting and also flags the conflicting areas. It is then up to the developer to decide if the version of developer A is to be the final version, or the version of developer B, or maybe a third version that is a synthesis of both versions. Once the developer has resolved this conflict, the file is then also merged.

So at the end of this update, the second developer has in his working copy a version of all files that corresponds to the latest revision in the working copy plus all his own changes. He can then easily commit those changes too, creating yet another revision in the repository.

The first developer then only has to do an update on his working copy to get those changes too.

That may sound a bit confusing now, but believe me, in real life it is actually very intuitive and will become second nature to you.

What you are asking about "locking" files so that only one developer can change them at a time is only necessary for binary files like typically images, sound assets, etc. Those can be flagged in SVN with the svn:lock attribute. (This flagging is usually done automatically by listing the filetypes of all files that are supposed to have this attribute, like *.jpg, *.png, *.wav, etc. in a config file). Flagging such a file has two effects:
First, the file is made read-only in the working copy, so a developer can not accidentially edit this file.
Second, to be able to edit the file (and make it writable), the developer has to acquire a "lock" for this file. However, SVN only grants the lock if no other developer currently has a lock on the file. So if you have PNG and your brother has already locked it for editing, and you want to acquire the lock too, you couldn't. SVN would tell you that it is already locked. Then once your brother commits the file (with changes) back into the repository, he thereby releases the lock and you could then first do an update (to get your brother's changes) and then acquire the lock yourself (to do your changes).
But as said, this is usually only necessary for binary files which can not automatically be merged by SVN.

And then there is of course all the other useful stuff of SVN, like the ability of going back to any older revision (in your working copy) at any time. Or the ability to diff-compare versions of a file from different revisions. Or the ability to set labels on revisions. Or the ability to branch off a second development branch (for example for a maintenance version) and later merge changes from this other branch back into the main branch. And, and, and...

And no, you don't have to shut down Visual Studio to do the updates, commits, reverts, etc. Even if you are not using an SVN client that integrates with VS. For example Tortoise: You would just make sure to save all files in all editors (VS, your image editor, whatever), and then you would do the update, commit, revert via the Windows Explorer integration of Tortoise.

Really, believe me and the others: Get SVN as soon as possible and you will never regret it!

Doc

Hey,

we're using TortoiseSVN for Zulu Hour (DBP trailer and playtest) and it is -as everyone else has said - invaluable, both for code and for someone like me who (only) does artwork.

Spyn Doctor:

And no, you don't have to shut down Visual Studio to do the updates, commits, reverts, etc. Even if you are not using an SVN client that integrates with VS. For example Tortoise: You would just make sure to save all files in all editors (VS, your image editor, whatever), and then you would do the update, commit, revert via the Windows Explorer integration of Tortoise.

Not only do you not need to close VS, but -assuming you've linked your files - you can have your project open, check out the latest revision from win explorer, then go back into VS, and it will automatically five you the option of updating all open files to the latest build, including your project content file. How cool is that?

K.

Stephen Styrchak:

Do you have any details about the problem that occurred?

From the sounds of it, you tried to build, it failed, and then you discovered that your source content was missing. Are you sure the missing content didn't cause the build failure in the first place?

What errors were reported by the build?
Did you examine the build log? (Every build logs output in the Output window.)
Were source files removed from the project (as shown in the IDE), or just deleted from disk?

I can certainly understand that under the pressure of trying to submit, you didn't spend a lot of time trying to evaluate what actually happened. However, I'm really, really skeptical that watching a youtube video caused VS to delete your source files. I have no doubt that you watched a video, or that your files were gone, but you haven't really provided any details to link the two, or even to explain why you think VS deleted your files.

Stephen, thanks for the attention on this bug.

I compile a ton of times per day, probably 50 or 100.  If the content was already missing, it would have caused a build failure numerous times before; not just on this final submission build.  I've tested this by compiling the project, then manually deleting the source content, and then re-compiling the project to see if the compiler was Ok with already having the compiled content.  It wasn't.  Each compile demands the source content to exist.

It's safe to assume the compiler deleted the files.  If this seems foolish, consider that VC6 had a similar bug prior to its SPs.  My directory of graphic content contains 21 folders & subfolders, so it would have been a difficult task indeed for anyone (i.e. myself) to have accidentally deleted all images but leaving the complex directory structure intact (I had to manually browse into each subfolder to see just what was deleted; I found all of it was, but the folders remained).

Sadly, I have no errors from the build log recorded.  I was in a hectic mess trying to fix the problem.  All I remember is a very complex DirectX error, which is not unlike the error that occurs whenever you attempt to compile PNGs when DirectX is active.  I can repro that bug at will, which reports an error like so:

"Error    1    Building content threw InvalidOperationException: D3DERR_INVALIDCALL
   at Microsoft.Xna.Framework.Content.Pipeline.CommonHelperFunctions.InitD3D()
   at Microsoft.Xna.Framework.Content.Pipeline.TextureImporter.InitD3D()
   at Microsoft.Xna.Framework.Content.Pipeline.TextureImporter.Import(String filename, ContentImporterContext context)
   at Microsoft.Xna.Framework.Content.Pipeline.ContentImporter`1.Microsoft.Xna.Framework.Content.Pipeline.IContentImporter.Import(String filename, ContentImporterContext context)
   at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.ImportAssetDirectly(BuildItem item, String importerName)
   at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.ImportAsset(BuildItem item)
   at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.BuildAssetWorker(BuildItem item)
   at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.BuildAsset(BuildItem item)
   at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.RunTheBuild()
   at Microsoft.Xna.Framework.Content.Pipeline.Tasks.BuildContent.RemoteProxy.RunTheBuild(BuildCoordinatorSettings settings, TimestampCache timestampCache, ITaskItem[] sourceAssets, String[]& outputContent, String[]& rebuiltContent, String[]& intermediates, Dictionary`2& dependencyTimestamps, KeyValuePair`2[]& warnings)
    Inner exception: COMException: Exception from HRESULT: 0x8876086C    C:\Visual C#\Windows Games\SpriteEffectsSample\SpriteEffects\Content\cat.jpg    SpriteEffectsXbox"

As you can see it's quite an in-depth error, which isn't common for most compile errors.  The graphic-deletion bug error was something like this.  I don't recall anything it said, expect it was huge in size like this, and that it was a DirectX error.

The source files were just removed from disk.  The directory structure remained in-tact.  The IDE's Solution Explorer also remained in-tact, showing a missing file for each content.  All of my files are 24-bit PNGs with transparency.  Nothing else was deleted.

I have no idea what caused the bug.  All I know is that DirectX was active.  The only programs that were active was FireFox 3.5 which was rendering a youtube video (paused) and the DBP 2009 submission site after having uploaded the 3 image files, awaiting the .CC game file.  The compilation was for Xbox 360/Release.  If an older app had been using DirectX that was still active, I would have known about it, since the next compilation would have also failed with the same DirectX error.  It did not; it complained about missing files.  I cannot repro this bug using Firefox 3.5 rendering youtube.  However, perhaps the DBP 2009 website used an add-on for the file uploader that uses DirectX?  I cannot attempt to repro this, since the DBP 2009 website is now offline for submission uploads.

To be clear: The error in compilation was NOT that the files were missing.  The error was a DirectX error like the above one.  The next immediate compile said the files were missing.  So, the files disappeared sometime between the first command to Build and the next command to Build a few seconds later.  :/  This is not the fault of whatever app was using DirectX.  The bug lies in the compiler.  To solve this bug, I'd recommend taking a look at the way the compiler/GS3.1 handles files.  Again this isn't the first time compilers have deleted files: VC6 and TMT Pascal did this all the time.  Perhaps a view into what VC6 was doing wrong may give some ideas about what VC# and GS3.1 are doing wrong.

I am willing to give anything required to help repro / solve this bug, including my source code and content.

Hey guys, I thought I'd chime in with some SVN help.

If you're looking at setting up an SVN/Subversion server on a local network (which is really needed if you've got slow internet), check out Martin Lindhe's blog. (If you're using Vista, you will have to right-click cmd.exe and run as administrator to enable the SVN service). You can do this on either of your current computers and it will give you plenty of leg-room for your projects; trust me, once you start with one repo you never go back!

If you have spare computer that is doing nothing, you could use it for a dedicated machine. I've got a bunch of tutorials on my site on doing just this task, look under the 'guides' section (http://phizz.ath.cx). For a quick installation, follow these guides in order:

1. Install Fedora 10 (this also applies for Fedora 11, you could also install some other Unix based OS but you may not have as straight forward success with the following guides).
2. Add RPMfusion repository.
3. Create a HTTP server using Apache.
4. Set up SVN server.

I made these guides awhile ago and feature the best bits of most of the tutorials I've read on the Internet about setting up an SVN server.

Ciao, Phill.

JasonD:

The bug lies in the compiler.  To solve this bug, I'd recommend taking a look at the way the compiler/GS3.1 handles files.

There isn't a compiler for content, and even if everything was deleted during the content build, that doesn't really tell us whether there's a bug in the XNA Framework Content Pipeline. The content pipeline, as I'm sure you know, is an extensible build coordinator that runs importers, processors, and writers. Those importers, processors, and writers can come from anywhere.

Do you have any custom content importers or processors? Do you have any content pipeline extensions that you got from a third party? Have you got any custom build steps or post-build steps in your project? Any of those could have done it as well.

The reason you get a stack trace for any exceptions caused during content builds is because many people write their own extensions. If we didn't provide the full stack trace, it would be a lot harder to debug customized pipelines. It's not a weird compiler behavior, because there's no compiler.

JasonD:

Perhaps a view into what VC6 was doing wrong may give some ideas about what VC# and GS3.1 are doing wrong.

You might as well tell me that Windows 3.11 used to crash a lot, causing people to lose data. :) VC6 shipped more than ten years ago, and I am quite confident that the code that runs during our content build is in no way related to VC6. The entire build engine, as well as the content pipeline components are all written in managed code. We didn't ship the first version of .NET Framework until VS7.

If you log a bug on connect and attach your project files to it, that might help us diagnose the problem. If you change your mind and don't want to submit your source files, just submit the .csproj and .contentproj files from your solution without the code files. Those will help us identify any custom build steps or custom importers/processors that you might be using. Or, it will show us that you weren't using any of those. In any case, unless it will repro, we don't actually need to run a build. (Although if you have custom importers, the source for those may be interesting.)

When you enter the bug on Connect, please describe which files were deleted (relative to the project files you attach), and which solution configuration you were building.

Stephen,

I know there's no compiler for content, but I was calling it that since the content properties call it "compile", so I thought that was the proper verb to use.

I don't have any custom content processors.  I don't have any custom build steps, or post-build steps.  The only thing that touches those files are the content processor for 24-bit .PNGs with transparency.  I will send you my project as-is so you can inspect all of this to ensure I'm not making any mistakes about this.

I know this doesn't narrow the bug source sufficiently, but at least you know it happened through the default build/compiler/content processing step of a regular build, with no 3rd party software getting in the way, due to a DirectX issue, with the strong likelihood that DirectX was in operation at the time.

I understand the purpose of displaying the large stack trace; it's certainly helpful, and had I copied this, we'd be one step closer to resolution.

I understand saying "look at VC6" seems a little foolish since it's old code.  I didn't mean to imply the code base was not entirely rewritten.  I didn't think it was the same bug.  What I thought was perhaps the concept that allows the bug was the same.  E.g. Maybe the file is foolishly opened for read/write access, when it should be read only, and a bug in the file pointer ends up erasing it.  A silly example, I know, but perhaps with the knowledge of the mistake in the past can help locate the current bug.  Who knows why any read-only process could delete a file, but it happens due to bugs, and knowing these bugs may reveal something.  It's detective work for an uncommon bug, I know.

One more possibility is that Windows Explorer may have been opened to one of the 21 subdirectories, since I had copied in some new images into that directory.  A mishap could have resulted in the deletion of these files, but it would not explain why the other 20 directories' files were deleted, with their directory structure intact.  However, Windows Explorer does strange things at times, like when trying to recreate thumbnail images, making it impossible to move/rename directories in the meantime.  Perhaps it was 'messing' with the directory at build time.  (I'll try and repro this.)

I will log a bug on connect.  The source files and content are 200 MB.  I would zip it up and upload, but that would make it public.  So, I should email you the source directly: I'll upload it to my webserver and give you a link to it.

JasonD:

I will log a bug on connect.  The source files and content are 200 MB.  I would zip it up and upload, but that would make it public.  So, I should email you the source directly: I'll upload it to my webserver and give you a link to it.

I thought there was a way to mark Connect bugs as "private", like for reporting security issues (otherwise hackers could just search through the reported bugs looking for unfixed flaws). Anyway, if that option only exists in my imagination, and you want to mail me a link, my username is stephen.styrchak, and the domain is microsoft.com. ...But please enter a connect bug so that I can attach the project to something in our tracking system. I'm not likely to be the person who ultimately ends up investigating this issue.

I don't think i have to sell using version control anymore than has already been done on this thread, but i am suprised that no-one has mentioned ankhsvn yet: http://ankhsvn.open.collab.net/

Stephen Styrchak:

I thought there was a way to mark Connect bugs as "private", like for reporting security issues (otherwise hackers could just search through the reported bugs looking for unfixed flaws).

Stephen, I've created a private connect issue (you were right, you can do this), and I am attaching the project files to it as I type.  The file is huge, and the upload window has frozen, but my internet is still being used, so I believe it's still en route.  If it fails, I'll try again.

The connect issue is: Compile deletes graphic files due to DirectX interference