User forums > Help
workspace file changes and source control
nanyu:
Looking forward this function come with nightly builds.
MortenMacFly:
--- Quote from: ironhead on December 17, 2009, 09:08:55 pm ---Again, I'm inclined to agree with you, in that I would normally not commit a workspace file to SCM.
--- End quote ---
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.
However, maybe that is because we have a QA process setup that is before every commit. So we not just commit, but review before. Thus such a modification easily gets spotted and thus can be ignored.
oBFusCATed:
Morten: Is there any chance, this patch can get into trunk?
At the moment I'm working cross platform, I've modified my project and now the whole project should be committed :(
So, with the current version I get no chance to see what I've changed in a particular revision.
MortenMacFly:
--- Quote from: oBFusCATed on October 08, 2010, 09:47:27 am ---Morten: Is there any chance, this patch can get into trunk?
--- End quote ---
Well in fact I've maintained this patch during the time and also using it.
The reason why I am not committing is the following serious drawback:
Well you have all your changes in the layout file now, but also the pointer to which project is the active one.
If you do commit the layout file you have the same thing happen: This will change often.
If you do not commit the layout file you are missing to point to the active project so C::B would set the first one as active which will break your compilation most likely if you do a clean checkout (take project dependencies into consideration). Also in this case I believe the active project in a mandatory information as it controls the build process and therefore should really remain in the workspace file or somehow provided to the developer. Probably a "default active project" can remain in the workspace and a "current active project" could be in the layout. But then: When and how to update the "default" one?!
I don't have a good idea how to resolve this so far... if someone has - step forward.
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.
oBFusCATed:
--- Quote from: MortenMacFly on October 08, 2010, 11:09:50 am ---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.
--- End quote ---
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 :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version