workspace file changes and source control

[raybert]

Hi,

I've set-up CB for my development team for cross platform development (Linux and Windows) and I've noticed some issues regarding changes to workspace files which cause (IMO) unnecessary source control commits.  I'm wondering if I should report this as a bug or change request or if there's something I'm missing to help control this.

The first issue is regarding the path separator characters.  If the workspace file is written on Linux it uses forward slashes and if written on Windows it uses backslashes.  This causes source control (Mercurial, in this case) to mark the file as changed and this then has to be dealt with by the developer when committing changes.  I really don't want tons of unnecessary commits of workspace files just because the slashes are different.  I see this as a bug or design flaw: CB should really standardize on one slash character for its project files and translate them internally as needed.

The second issue is regarding the active project, which is apparently recorded in the workspace file.  This means that if a developer activates a project and the workspace file later gets saved (which usually does end-up happening, CB even nags you to save it) the workspace file is then considered changed by source control and the same issue as above ensues.  We need the workspace file under source control because it records vital project dependencies.  It seems to me though that something such as which project is active should be stored in a different file -- one which is not intended to be under source control (a layout file, perhaps?) -- in order to avoid this issue.

I'd appreciate any input that folks may have on this.

Thanks,

~ray

[MortenMacFly]

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?

I'll propose another idea: I don't know mercurial but SVN offers pre-commit checks. These can call a pre-commit tool before the actual difference is computed. Knowing that a workspace file is just XML it should be an easy task to setup a tool that takes care of e.g. "fixing" the back-slashes. The rest I don't know how to properly handle. IMHO it's up to the dev to decide what (s)he wants to save (thus to commit).

[killerbot]

I can understand the OP, we have the same issue with the version control system ClearCase.

I do think, CB should use in the project files / workspace files either forward slashes or backward slashes. I would suggest forward slashes (event without a version control when you want to compare sources between windows / linux these / \ differences are annoying).
That CB can handle them both is good, for it's multi platform support, but the xml files are for CB. And either work on both operating systems, I know, since I mix them a lot, and as long as you don't (re)save your project, nothing changes.

And I don't think we should expect users to whatever pre-commit or create filters whatsoever. This is just not user friendly, it's our job to do better ;-)
Then it will be solved for everyone, because a user shouldn't bother how CB stores it's information internally.

Note that CB's xml files are easy to understand, which can not be said for other IDE's (some of them put their version number in the project file, something like 9.0, but depending on the locale that can become 9,0, guess which company made such a stupid thing  :mrgreen: )

As for the workspace, one can work around it by not saving it when CB asks you to do so. Counter intuitive maybe.
But there a e few other things wrong with the workspaces, maybe all of them one day could be tackled.

[MortenMacFly]

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.

[MortenMacFly]

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

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

WRT slashes in the workspace file, this is a CB file exclusively

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]

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

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.

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

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

[MortenMacFly]

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

Anyways - I think the topic has been discussed enough. Time to get hands on and provide patches...

[raybert]

hmm... so, if I save a workspace on Linux, commit it to source control, refresh my Windows work area, and then try to convert it using one of these tools, it will fail because the tool doesn't bother to check the slashes?

If that's the case then I would argue that the tool in question has a bug.

As for patches, I was thinking last night that if I patch CB and make my team use the patched version then that's one way forward for me (and it's cleaner than using VCS hooks).  I imagine that these patches wouldn't be very difficult.  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).

~ray

[MortenMacFly]

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.

[raybert]

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

The attached patch (against svn 5456) causes filenames in workspaces to be always written with forward slashes.  It also disables saving the active project.  Additionally, it prevents the workspace from being marked dirty when the active project is changed (doesn't make much sense to do that if it's not being saved anyway).

One thing it doesn't do is to save the active project in a different file as I suggested earlier.  I don't need that for my own use but, if it's desired, it shouldn't be hard to do (and I'll try to find time to do it).

This is my first patch and I'm not sure of the protocol here.  Should I post this to the tracker as well?  I have a few more itches to scratch so this probably won't be my last.

~ray


[attachment deleted by admin]

[killerbot]

yes, please add if through the tracker on our berlios page, so it won't get lost ;-)