User forums > Help
workspace file changes and source control
killerbot:
calm calm.
Everybody is overlooking something, the workspace file, the project file are internal CB files !!!
And therefor I *think* forward/backward slashes will work whatever you use, and wherever you use it.
I use backslashed cbp files on linux, and forwardslashed cbp files on windows, an I haven't encountered any issues.
This is most probably because CB those some translations to native on the inside.
That's why I think, that for example just using forward slashes will not introduce any issues.
Always something we can try out ...
raybert:
Hi guys,
Thanks for the comments. Some follow-ups:
WRT slashes in the workspace file, this is a CB file exclusively so there is absolutely no need for the paths contained within to match the native file system. CB can already handle either slash on both input and output. The real issue here is about CB itself being consistent. Why should it use two different formats? That's inconsistent. It should use one everywhere.
If you have a cross-platform workspace then the slashes used in the workspace file are always going to be "wrong" on one platform or the other. If you save it on Windows you'll have backslashes when you return to Linux and vice-versa. So there's really no meaning to matching the native file system in the first place.
It's clear to me it should use only one, consistently. The file:// URL suggestion also seems reasonable, if one wants to be really anal about this, but I personally think that doing that is overkill. There's really nothing wrong with always using forward slashes (for example).
As for the active project issue, I'm not sure I agree that this information is important to the project configuration (it certainly isn't useful to me). If you can cite an example of when this might be important I might change my opinion. In most cases, programmers are going to have to purposely change the active project while they're working for one reason or another. They should understand what each project is and know which one they need at any given time. Also, each project should build independently, so this is not an issue of the build failing if you don't have the "correct" project activated (maybe you won't get the build you wanted, but a programmer that can't handle that is not someone I want touching my code!).
I therefore consider the active project setting to effectively be a project-specific *user preference*. I think we can agree that user preferences should be stored separately from project configuration.
The suggestion of using a VCS commit hook (yes, Mercurial does have them, BTW) is not a bad idea as a work-around. But it's important to understand that that's all it is: a work-around. CB shouldn't make work-arounds necessary as a matter of course.
BTW, I'm not sure if it's possible to write a VCS hook that *modifies* the file being committed because the changes would have to be propagated back to the person doing the commit. If you can't do that then the person's working copy is immediately dirty after a commit (WRT to the central repository) and that's going to really goof people up. You would have to reject the commit altogether, I think. And that means that developers are going to be forced to omit the workspace file from their commit and/or revert the changes to it. And they're going to have to do this *all the time*. I don't think it's reasonable to force that on folks.
As for the suggestion of relying on developers to NOT save the workspace file, um, yeah, right. :D There are all different levels of developers and even the best are going to forget occasionally. I personally like to use "save everything" when I have changes rather than deal with multiple nag prompts to save things. If I have to avoid saving the workspace file then I effectively can no longer do that and I have to live with all the nags. Also, isn't it possible to turn the nag prompts off? If I remember that correctly, and someone does turn them off, they're going to be saving the workspace file all the time without even realizing it!
Thanks again,
~ray
MortenMacFly:
--- Quote from: raybert on April 13, 2009, 06:31:49 pm ---WRT slashes in the workspace file, this is a CB file exclusively
--- End quote ---
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".
raybert:
--- Quote from: MortenMacFly on April 13, 2009, 06:52:38 pm ---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...).
--- End quote ---
These changes shouldn't break any third-party utils though:
- Any such tools already have to deal with both slashes (because they already differ depending on which OS you saved the workspace under).
- The "active" attribute is optional on any given "Project" tag so no tool should require it to exist.
--- Quote from: MortenMacFly on April 13, 2009, 06:52:38 pm ---- 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".
--- End quote ---
I certainly would not mind that. My only goal is to make the content more consistent and avoid unnecessary changes.
~ray
raybert:
Just thought of something: if you use file:// URLs then that WILL break third party tools. So this seems to be a good argument for sticking with simple directory paths with one type of slash (forward, preferably).
~ray
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version