Given this structure:
$/TeamProject/
Project A/
Development [Branch] <-- Labeled "v1.0" # latest
Project B/
Development [Branch] <-- new pending v1.0 release
Product A already has a label "v1.0" set on its Development Branch.
But now when I try to label Product B branch with label "v1.0", VS is saying that that label already exists and will be overwritten?
How can this be when the Project A label was set on the Project A branch and has nothing to do with the Project B branches.
Product A and Product B are part of the same system but are released independently as and when they are updated.
Is this a bug or am I missing some step to the process.
I am using the VS Team SCE as I prefer to use a GUI than CLI.
I have read somewhere that a label has scope, surely when you set a label on a folder in VS it sets that folder as the scope, no?
Thanks,
Gary.
In case it helps anyone.
According to http://msdn.microsoft.com/en-us/library/ms181439(v=vs.80).aspx (the vs2010 one does not mention this but it still applies):
Labels created within the graphical user interface are scoped to the root folder of the team project within which they are created. Labels created from the command line are scoped to the longest common path shared by the items specified in the label command.
Not sure why MS have chosen to do this, as you can right-click a branch / folder and select "Apply Label" which is kind of misleading.
Related
I have a project in TFS that has been live for a year. In June we made our final release (we labelled the sources) before we began a massive 3 month overhaul during which the live site would not change.
Unfortunately we are now required to make a change to the live site and the codebase has changed significantly. What I want to do ideally is check-out by label the final release (June) into another folder and check that in to TFS to create another project. This way my team can work on both projects.
How can I best achieve this?
You should create a branch. This doesn't need to be in a new project. In fact it would be better if it wasn't, however depending on your folder structure keeping it in the same project might not be an option.
Right click on the root of the folder you want to branch. This should be the folder highest in your folder structure that contains all of the code you want to modify.
On the right click menu select "Branching and Merging" and then "Branch"
Choose a sensible location for the new branch.
In the dropdown select "Label" then choose the appropriate selection.
Hit branch. This will create a new branch from the label and you will be able use the new branch to modify your live code base
I have a solution S with 2 projects, A and B. B needs the exe of A as an embedded resource.
So I right click on B > Add > Add existing item... > I pick [...]\S\A\bin\debug\A.exe and for this new item I set Build Action = Embedded Resource.
Everything works well. But if I look to such item's Full Path property I see the path [...]\S\B\A.exe. This means that any rebuild of project A won't affect the embedded resource in project B.
How can I keep embedded resource in project B up-to-date with the original exe resource produced by project A?
Yes, this is by design. The IDE normally copies the resource into your project directory, a strong counter-measure to help you avoid some bad day in the future where you can't build your program anymore because the resource is missing and you forgot to make a backup.
Which is not what you want here. Remove the item and use Add + Existing item again. Note that there's a down-arrow glyph on the Add button. Click that arrow and pick "Add as Link". Now that copy won't be made and your project will refer to the actual file.
You still have to ensure that A.exe is available and up to date before you build B. Right-click the B project in the Solution Explorer window, Build Dependencies and tick the A project. A will now always be built before B.
I have a project hosted on GitHub, the active branch of which is called dev. Since yesterday, Aptana shows [dev+1] next to the project folder. Before yesterday, it's only shown [dev]. What does [dev+1] mean?
Please see the screenshot below:
Here is the answer from the Aptana Documentation: (I highlighted the important note)
Our Git support will make git-specific modifications to the UI for
related projects and files. In particular, unstaged files will
typically be shown with a red background color in Project and App
Explorer; staged will show with a green BG. Files with any uncommitted
changes will show with a * (asterisk) "dirty" indicator, and folders
will show the dirty indicator when any file inside it's hierarchy is
dirty. Projects will show the current branch inside square brackets to
the right of the project name inside the Project Explorer. The branch
name will be followed by a + or - and number if there are committed
changes to be pushed or pulled from a corresponding remote.
I can't find anything workspace related in the Xcode Build Setting Reference.
Essentially I need something like $(WORKSPACE_DIR). If Xcode doesn't provide it, is there any way to define a custom user variable that could somehow accurately provide the workspace path in the event that the working workspace were to move (think branches etc)?
If your workspace is set up like:
//bla/bla/bla/workspace/{project directories}*
then you can use
$(SRCROOT)/../
to get the workspace directory from a give project directory.
For example, if you want to have one project reference headers in another project:
Project Build Settings->User Header Search Paths =>
$(SRCROOT)/../SomeLibProj
(and set it to 'recursive' if you don't want to add every folder)
Custom variables can be defined under build settings. I think there is a button named Add Build Setting. So, a new variable workspace root can be defined relative to the SRCROOT or use absolute path.
The new setting is shown under "User Defined" group in build settings. "Add Build Setting" button is near lower right corner.
I'd like to recreate a folder hierarchy like in this example (from TFS Branching Guide Main 2010 v1):
The problem is I cannot understand how to create additional root-level folders, like those Development and Release in the picture above, to put new child branches into. The New Folder command option becomes available only at levels beneath root-level branches.
How to create new root folders in a Team Project source control at the Main branch level?
Make sure that your workspace maps at the Team Project level ("StandardBranchPlan" in the picture). I just tried this, and found that "New Folder" does not appear if I have the wrong workspace selected, but once I select a workspace that maps the folder under which I want to create a new folder, "New Folder" became enabled.
Here is what I did.
Connect to the desired collection in Team Explorer.
Click the down arrow at the end of the "Connect" row.
From the drop-down menu provided select "Projects and My Teams".
Select "New Team Project".
And now you have a new "Directory" under the collection root.
You cannot add a folder to root in TFS to an unmapped as mentioned. However one good way to do this is with the following example.
Scenario:
You want to have a NEW Folder to contain many NEW Projects
Right click on your solution and Add solution to source control
At this point you can create a folder on root with say name of "WebServices"
Then you continue through with the popup in adding in your project/solution
For me this works fine, although I too would prefer the freedom to setup a folder structure ahead of time for myself and other developers without having to commit/check-in code etc.