workspace file changes and source control

[MortenMacFly]

I finally got around to working on a patch to address these issues.

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);

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]

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);

This breaks C::B's ability to detect a change in the workspace.

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.

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.

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]

any time another project is activated (and the workspace file is saved), the SCM tool will detect the change and prompt for a commit.

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.

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.

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.

[Seronis]

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.

Wouldnt this be useful for the instance where you have multiple developers and a few of them happen to work on the project from multiple different locations?

[MortenMacFly]

Wouldnt this be useful for the instance where you have multiple developers and a few of them happen to work on the project from multiple different locations?

What I meant was: If you do use version control why would you still allow several devs to work in one (file) place? I mean: version control is exactly the tool needed to avoid conflicts that will surely arise if several people work on the same file base.

Thus the best way is everybody having it's own working copy which renders the USER prefix useless... just my 2 cents.

[ironhead]

Thus the best way is everybody having it's own working copy which renders the USER prefix useless... just my 2 cents.

Fair enough, I do agree with you here.

Regarding:

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?!).

Again, I'm inclined to agree with you, in that I would normally not commit a workspace file to SCM.  The challenge is that project dependencies are stored in the workspace file (i.e. Project X depends on Project Y) so without committing the workspace file, someone checking out the source may have build failures due to projects being built in the wrong order.

I will try out this patch hopefully next week (I have to admit I haven't actually tried it yet, I was just going based on the description).

[killerbot]

Yes, the fact that project dependencies re in the workspace, is sometimes a game spoiler.

What would the cons for putting those dependencies in the project file ?

[oBFusCATed]

I vote 100% for putting deps in the project file.
At work we have around 60 project 5-10 solutions, half of the projects are libs.
It is great pain to create a new application that depends on several libs.
We are using VS 2005 .
It costs lots of time, that can be save with that feature. Let us beat the M$!
Also it could be possible to automatically load the dependant projects.

[nanyu]

Looking forward this function come with nightly builds.

[MortenMacFly]

Again, I'm inclined to agree with you, in that I would normally not commit a workspace file to SCM.

YOu misunderstood. Surely I am comitting the WS file to SCM. But only at times where I setup the WS or modify it (moving projects, adding / removing projects, changinfg dependencies). What I meant is that I will not commit the WS file if only the active project is changed and this makes no sense for other devs, too.

However, maybe that is because we have a QA process setup that is before every commit. So we not just commit, but review before. Thus such a modification easily gets spotted and thus can be ignored.

[oBFusCATed]

Morten: Is there any chance, this patch can get into trunk?

At the moment I'm working cross platform, I've modified my project and now the whole project should be committed
So, with the current version I get no chance to see what I've changed in a particular revision.

[MortenMacFly]

Morten: Is there any chance, this patch can get into trunk?

Well in fact I've maintained this patch during the time and also using it.

The reason why I am not committing is the following serious drawback:

Well you have all your changes in the layout file now, but also the pointer to which project is the active one.

If you do commit the layout file you have the same thing happen: This will change often.

If you do not commit the layout file you are missing to point to the active project so C::B would set the first one as active which will break your compilation most likely if you do a clean checkout (take project dependencies into consideration). Also in this case I believe the active project in a mandatory information as it controls the build process and therefore should really remain in the workspace file or somehow provided to the developer. Probably a "default active project" can remain in the workspace and a "current active project" could be in the layout. But then: When and how to update the "default" one?!

I don't have a good idea how to resolve this so far... if someone has - step forward.

For the moment - always using forward slashes (the unix way) in the project and workspace files (so partially applying this patch) might be something better.

[oBFusCATed]

For the moment - always using forward slashes (the unix way) in the project and workspace files (so partially applying this patch) might be something better.

If you can apply this part of the patch I'll be 99% happy, the active project is manageable (you can easily revert the change before committing), but the slashes are not