I'd appreciate any input that folks may have on this.Well - the workspace is modified if the user saved it by choosing the appropriate "Save" command in C::B or answering "Yes" if C::B asks to save the modified workspace. In that case how to differ whether a dev was just "lazy" or really wanted to save something? Depending on the workspace setting a different active target might be vital for development (that's why it's in the workspace file). So how to differ again if a dev did it on purpose or not?
This is just not user friendly, it's our job to do better ;-)Depends on the view. I personally think that if a filename is provided in a workspace file (which is) it should be a OS native filename. Under Windows a path containing forward slashes is not native and does not even function. The only solution I see is to use a protocol like file:// or alike. This would again be "native" and correct on all platforms.
Forward slash path separators in source code work on all platforms because the compilers are required by market forces to accept UNIX source code.In case you did not realise: We are not talking about source code here, but a workspace file. Better read twice before "Bzzting"... ;-)
WRT slashes in the workspace file, this is a CB file exclusivelyWell - I am open for everything. Just keep two things in mind:
Well - I am open for everything. Just keep two things in mind:
- There are already converter around that convert C::B projects (workspaces) to different IDE's. So we break the current format as we introduce a new version (we did it already in the past...).
- Looking at other cross platform IDE's and how they handle file pointers still makes me believe that if we do a change it should be something like a file:// protocol which is "native".
- Any such tools already have to deal with both slashes (because they already differ depending on which OS you saved the workspace under).Exactly not. That's my point: The tools just "copy" the content as a file string. This then is used to open the file pointer using (probably) OS calls. So if we change the path forward slashes on Windows such functionality won't work anymore.
So I will likely try to find some time to work on this and I'll submit my patches (even if the devs ultimately decide not to commit them).Sounds good to me. Notice that we do discuss patches internally. So it *is* likely it will be applied as at least one other dev pro's the modification... ;-) That I don't like it doesn't necessarily mean a show-stopper.
I finally got around to working on a patch to address these issues.Two notes:
- if (m_pWorkspace)
- m_pWorkspace->SetModified(true);
+// if (m_pWorkspace)
+// m_pWorkspace->SetModified(true);
Two notes:
1.) I don't get why you do this:CodeThis breaks C::B's ability to detect a change in the workspace.- if (m_pWorkspace)
- m_pWorkspace->SetModified(true);
+// if (m_pWorkspace)
+// m_pWorkspace->SetModified(true);
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.
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?!).
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.
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?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.
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.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.
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.
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 :)