It is sometimes better to do the planning before taking the first step.

I would appreciate it if you could add the following two use-cases to your design document. 1. A coder creates a workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the code ( NOT SUPPORTED! ) 2. A coder forks an existing workspace ( currently supported ); adds some code to it ( currently supported ); writes an article about the changed code ( NOT SUPPORTED! ) I would also be curious as to what use-cases you do support. The above two seem to me to be the most obvious from where I sit. You seem to have just the following 3. An old article exists with some code in a zip; a workspace is automagically created containing the zipped code and linked to the existing article; the coder can check in changes to the workspace This ( uses-case #3 ) is a very nice feature, but not the first I would have implemented myself. Surely everybody is most interested in creating new content rather than fiddling around with old articles. Or is that just me?

OK, I tried doing it your way. I have created a new article: http://www.codeproject.com/script/Articles/ArticleVersion.aspx?waid=129995&aid=787134[^] Where is the workspace?

I think I am beginning to understand! The only way to create an article/workspace pair that are connected together is to create the article FIRST. An empty workspace will be created, paired with the new article. Later on, I can add code to the workspace. Is this correct? Have I finally understood this? Comment: This seems backwards to me. Surely the natural way of proceeding would be to write the code first. Once the code is working and tested, then a person might think to write an article describing it. I cannot really imagine a situation where I would write an article before writing the code. The article might, I suppose, be a requirements document and a test plan, but that would be about all - not very interesting. And, of course, the enormous resource available of existing workspaces becaomse significantly less useful if we cannot fork them. Finally: I think you need to document this behavior somewhere prominent, since it is so counter-intuitive

" if you manually make a fork of an article, you cannot bind it with any articles" Actually, you did NOT say that. You said: "the bindings between articles and workspaces are done automatically" Please explain the correct procedure so that I can bind my workspace to my article. Is the problem something to do with the fork? Should I start a new workspace?

"the bindings between articles and workspaces are done automatically" Well, then there seems to be a bug in this process, because I have an article which describes the code in a workspace, and they have not become connected. The workspace is here: https://workspaces.codeproject.com/ravenspoint/simple-dxf-readerviewer-with-spline-support[^] The article is here: Simple DXF Reader/Viewer with Spline Support[^] Do I have to do something special to register this bug?

The welcome message says: " ... without attaching the workspace to an article if you wish." OK, but what if I DO want to attach a worrkspace to an article? I have an article which describes the code in a workspace. How do I attach them to each other?

Existing articles have been 'automagically' connected with a workspace holding their code. Very neat! How do I connect a new article to a new workspace?

I submitted an article, which has been edited ( by Deeksha Shenoy. Thanks! ) How do I contact the editor? I received a note, suggesting I contact the editor to finalize a detail. However the note was sent from an unattended mailbox and there is no obvious contact button on the editor's profile page, so I am kind of stuck.

Yes, I called git remote add from inside the repostory folder. The problem seesm to do with adding a remote origin to an existing git installation which already has an origin set.

The problem seems to be with naming the remote as 'origin'. I already use git with another repository. So there is already a remote called 'origin' which causes problems. Things work better if I choose another name

James@MILLER ~/Documents/test4 (master)
$ git remote add t4 https://git.codeproject.com/ravenspoint/dxfvtest4

James@MILLER ~/Documents/test4 (master)
$ git remote -v
origin
t4 https://git.codeproject.com/ravenspoint/dxfvtest4 (fetch)
t4 https://git.codeproject.com/ravenspoint/dxfvtest4 (push)

James@MILLER ~/Documents/test4 (master)
$ git pull t4 master
remote: Counting objects: 47, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 47 (delta 8), reused 0 (delta 0)
Unpacking objects: 100% (47/47), done.
From https://git.codeproject.com/ravenspoint/dxfvtest4
* branch master -> FETCH_HEAD
* [new branch] master -> t4/master

Yes. Note the instructions ( Working with CodeProject Workspaces::Code (::GitMachine)[^] ) say to do the init afterwards. I have tried both

I have tried forking an existing repository, and creating a new empty workspace but I cannot connect to them

$ git remote add origin https://git.codeproject.com/ravenspoint/ws
fatal: Not a git repository (or any of the parent directories): .git

I have discovered a simple, almost crude, solution for this problem. Remove the VERSIONINFO resource. Now the installer will delete the old installed file and replace it with the one in the installation package. To remove the VERSIONINFO resource: - Open the resource view - Open .rc - Open Version - Right click on VERSIONINFO - Delete

I am accustomed to RemovePreviousVersions uninstalling the previous version and installing the new one. I just need to increment the version number, accept a new product code and leave the upgrade code untouched. But the vs2008 msi leaves the old versions of the files in the installation folder. I have read that this is because vs2008 checks the version of the individual files, and if they have not changed, refuses to install the new file. OK. So how do I increment the version number of the individual files? I do not want to have to change each file manually! Thanks, James

I suppose you want something that is free, requires zero installation, and is very simple. I have been using zoho creator for a month or two, and it does the job. They have a "bug tracker" which you can start with, then customize with added fields and drop down lists, etc. You can make the UI, which looks like a spreadsheet, appear anywhere on your website, even inside one of your pages, without having to install anything on your server. I think it is a good place to start people off on bug tracking. The simplicity will not intimidate most, and if they like using it and begin calling for sophistication and integration, then they will be motivated to install a client on their systems, and to pay you to install a server.