User forums > Help
workspace file changes and source control
MortenMacFly:
--- Quote from: raybert on April 24, 2009, 04:36:34 am ---I finally got around to working on a patch to address these issues.
--- End quote ---
Two notes:
1.) I don't get why you do this:
--- Code: ---- if (m_pWorkspace)
- m_pWorkspace->SetModified(true);
+// if (m_pWorkspace)
+// m_pWorkspace->SetModified(true);
--- End code ---
This breaks C::B's ability to detect a change in the workspace.
2.) Are you aware that wxFileName has it's own Windows/Unix convertion of path names? Check the wxPathFormat enum (see http://docs.wxwidgets.org/2.8/wx_wxfilename.html) for that purpose. This way you don't need the ExportFilename method at all.
Other that that I am surprised that this is such a minor change... But it seems to work though... :shock:
raybert:
--- Quote from: MortenMacFly on April 24, 2009, 09:02:15 am ---Two notes:
1.) I don't get why you do this:
--- Code: ---- if (m_pWorkspace)
- m_pWorkspace->SetModified(true);
+// if (m_pWorkspace)
+// m_pWorkspace->SetModified(true);
--- End code ---
This breaks C::B's ability to detect a change in the workspace.
--- End quote ---
No, it only avoids marking the workspace dirty when a project is activated (the change is in ProjectManager::SetProject()). All other workspace changes are still recorded.
--- Quote from: MortenMacFly on April 24, 2009, 09:02:15 am ---2.) Are you aware that wxFileName has it's own Windows/Unix convertion of path names? Check the wxPathFormat enum (see http://docs.wxwidgets.org/2.8/wx_wxfilename.html) for that purpose. This way you don't need the ExportFilename method at all.
--- End quote ---
My goal wasn't to change filename format, only standardize the slashes. So I used the same file name format that CB would have normally written except I force backslashes to forward slashes before writing.
This works in the workspace file because all of the paths written there are forced to be relative paths (relative to the workspace file) and relative paths look the same on Unix and Windows (notwithstanding the slashes).
~ray
raybert:
Hi,
I've significantly updated the patch that I previously posted. It's a much more complete solution now. However, I included a couple of (minor?) additional behavioral changes that I'd like to hear feedback on. I'll also post this to the tracker shortly. Note that this new patch contains all the changes from the previous version.
The new changes are:
* Now creates a "workspace layout" file that records the active project and something new called the "preferred target" (more in a moment). In order to avoid overwriting project layout files (in the case where the workspace and a project have the same name) I've used the filename extension ".workspace.layout". So a workspace file called "foo.workspace" will now have a companion layout file called "foo.workspace.layout". (The intention, of course, is that nothing should be placed in this file that should be in source control, similar to the project layout file.) I'm not sure that I caught all of the conditions in which the workspace layout file needs to be written; I'd appreciate feedback on that.
* Added the concept of a "preferred target". I found the previous behavior of changing the user-selected build target whenever a project was activated to be annoying. I've often found myself building the wrong target because I forgot to check whether CB changed it on me. Now, when a user selects a build target, it gets set as the "preferred target" and CB will try to maintain it as the selected build target when new projects are activated (this is not possible of course when a given project does not have the preferred target). It also saves the last preferred target in the workspace layout file so that it will be restored when the workspace is loaded, if possible. This solution seems to be a reasonable compromise to the problem.
* I modified the target drop-down (and menu) list so that it does not show targets that are not supported on the current platform. If you have a project that has no supported targets then the list ends-up being empty. I'm not sure if anything needs to be done about that.
Please let me know what you think of these changes.
Thanks,
~ray
[attachment deleted by admin]
ironhead:
Sorry for resurrecting such an old thread, but I think there is a lot of merit in having the .workspace.layout file contain the more transient workspace information. Having the active indicator in the workspace file causes issues with SCM tools due to the fact that any time another project is activated (and the workspace file is saved), the SCM tool will detect the change and prompt for a commit.
Edit: taking it one step further, it would be nice to have .workspace.layout.$(UserID) (or some variation thereof) so each user can have their own transient file.
MortenMacFly:
--- Quote from: ironhead on December 17, 2009, 04:43:03 am ---any time another project is activated (and the workspace file is saved), the SCM tool will detect the change and prompt for a commit.
--- End quote ---
Well fr me it's very simple: I simply don't commit that file then. Hence I am already testing this patch for some time now. One thing I don't like is that if you don't have that layout file (for me it's always after creating a clean checkout) not project is activated because there is no fall-back for the case the layout file is not present (which can of course happen and should be considered). Additionally it happened to me that the workspace file was modified but C::B did not tell me (probably because I did not have a layout file?!).
I had in mind to look into that but I am very limited in time atm. So - if you want to help, try the patch and help fixing the bugs I mentioned.
BTW: Please refer to patch #002748 for that purpose, not the one in this forum.
--- Quote from: ironhead on December 17, 2009, 04:43:03 am ---Edit: taking it one step further, it would be nice to have .workspace.layout.$(UserID) (or some variation thereof) so each user can have their own transient file.
--- End quote ---
That means you are working on the same code base (file base) with several developers? Why do you need version control then? I don't see the benefits from doing this. Because any layout file should not be under revision control. Thus everybody that creates an own workspace will ultimately have it's own layout file.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version