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.
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