User forums > Help
workspace file changes and source control
Seronis:
--- Quote from: MortenMacFly on December 17, 2009, 07:11:20 am ---That means you are working on the same code base (file base) with several developers? Why do you need version control then? I don't see the benefits from doing this. Because any layout file should not be under revision control. Thus everybody that creates an own workspace will ultimately have it's own layout file.
--- End quote ---
Wouldnt this be useful for the instance where you have multiple developers and a few of them happen to work on the project from multiple different locations?
MortenMacFly:
--- Quote from: Seronis on December 17, 2009, 06:28:18 pm ---Wouldnt this be useful for the instance where you have multiple developers and a few of them happen to work on the project from multiple different locations?
--- End quote ---
What I meant was: If you do use version control why would you still allow several devs to work in one (file) place? I mean: version control is exactly the tool needed to avoid conflicts that will surely arise if several people work on the same file base.
Thus the best way is everybody having it's own working copy which renders the USER prefix useless... just my 2 cents.
ironhead:
--- Quote from: MortenMacFly ---Thus the best way is everybody having it's own working copy which renders the USER prefix useless... just my 2 cents.
--- End quote ---
Fair enough, I do agree with you here.
Regarding:
--- Quote from: MortenMacFly ---Well fr me it's very simple: I simply don't commit that file then. Hence I am already testing this patch for some time now. One thing I don't like is that if you don't have that layout file (for me it's always after creating a clean checkout) not project is activated because there is no fall-back for the case the layout file is not present (which can of course happen and should be considered). Additionally it happened to me that the workspace file was modified but C::B did not tell me (probably because I did not have a layout file?!).
--- End quote ---
Again, I'm inclined to agree with you, in that I would normally not commit a workspace file to SCM. The challenge is that project dependencies are stored in the workspace file (i.e. Project X depends on Project Y) so without committing the workspace file, someone checking out the source may have build failures due to projects being built in the wrong order.
I will try out this patch hopefully next week (I have to admit I haven't actually tried it yet, I was just going based on the description).
killerbot:
Yes, the fact that project dependencies re in the workspace, is sometimes a game spoiler.
What would the cons for putting those dependencies in the project file ?
oBFusCATed:
I vote 100% for putting deps in the project file.
At work we have around 60 project 5-10 solutions, half of the projects are libs.
It is great pain to create a new application that depends on several libs.
We are using VS 2005 :(.
It costs lots of time, that can be save with that feature. Let us beat the M$!
Also it could be possible to automatically load the dependant projects.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version