User forums > Help

workspace file changes and source control

(1/7) > >>

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:

--- Quote from: raybert on April 11, 2009, 12:42:00 am ---I'd appreciate any input that folks may have on this.

--- End quote ---
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:

--- Quote from: killerbot on April 11, 2009, 09:56:01 pm ---This is just not user friendly, it's our job to do better ;-)
--- End quote ---
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:

--- Quote from: ancient nuby on April 12, 2009, 11:26:35 pm ---Forward slash path separators in source code work on all platforms because the compilers are required by market forces to accept UNIX source code.

--- End quote ---
In case you did not realise: We are not talking about source code here, but a workspace file. Better read twice before "Bzzting"... ;-)

Navigation

[0] Message Index

[#] Next page