I have a simple branch plan with a main and a development branch. In the development branch I have beside the source code some documents related to the development process which should not be merged to the Main branch upon merging the latest version of development to main. Is it somehow possible to mark specific files or folders in the source control as 'ignore' for merging?
Thanks for your help.
I think the simple answer is, if you don't want to version control the documents along with the code then move them out of the branch :-)
If you still want the documents to be near the code they describe, but you don't want them promoted between branches then you could try to cloak the folder(s) containing the documents in your workspace (the folder in the main branch) TFS will ignore the folder when it performs a merge.
e.g.
$/[TeamProject]/[DevBranch]/Docs --- (not cloaked, so you can check the docs in and out)
$/[TeamProject]/[MainBranch]/Docs --- (cloaked, merging at the root of the branch will ignore this folder)
Related
Good Morning,
I am working on legacy code. This legacy code consists of multiple projects (language C with NI LabWindows CVI) and was never manged in a source control System but only in on folders. Over time it got a little messy and copies of this folder were created and changes were made to all folders depending the project that was built.
The result is, that there are 5 folders each containing different codes bases for what once was the same code. Also many files were modified in all folders because they are used in several projects. Each project was only build from 1 of the 5 folder (so project A was only build in folder 1, project b in Folder 4 etc.). It is not only raw code, but also user interface files.
I hope that was clear so far.
My task is to merge all the code into one one codes base (as it started of originally). And I would like to get some suggestions.
Here is the plan:
1. create baseline version of one folder that is supposedly that one with the most changes.
2. create GIT repository to store the code and all changes
3. go through all folders and merge files into baseline version using file diff software. (Folder 1 is baseline, merge folder 2 to baseline, merge folder 3 to baseline etc.)
Do you have any comments on this plan? What is good? Bad? Are there tools I can use?
This seems like as good of a plan as any. You have a mess on your hands either way.
If there are many changes to the user interface panels, that could be a headache. The UIR files are binaries, which will make git merges and diffs useless.
Go into each project and under Options->Preferences select the box to save .UIR files as .TUI files and save the project. This will give you a text file output describing the user interface and allow you to use diff tools properly.
EDIT
When the User Interface is active, you can directly select Options->Save in Text Format to do this as a one-off.
Good Luck!
It might also be worthwhile to use the UI to Code converter under CVI's Tools menu to convert all your UIRs to code. This should make them more compatible with text-based source control (like the save in text format approach), but may also ease the process of merging UIs.
I need to modify a Simulink project stored under clearcase. From this project I must generate the C code, but this not the problem. The problem is that all generated files (*.c and other) are saved into clearcase and the code generation delete some file without overwrite the old version with new. Fortunately seems only for files different from *.C but in any case under clearcase (I use a windows client) I found in correspondence of deleted file:
the file name
three colored question marks
I think that clearcase has the information regarding the file stored but is not able to allocate this.
Now I need a command/script for CC which help me to found ALL removed files from the view because the project structure is very complex and a manually search is hard.
Thanks for any suggestion
"three colored question" marks means "checked out but removed", as in this example (you can recover from it by reloading the snapshot view)
If an automatic process is generating or deleting files in a snapshot view (it wouldn't be able to do the same in a dynamic view), then you should end up with a bunch of hijacked files (as identified in a snapshot view).
You could check them out and check them in.
For the files that need to be deleted, you can follow "What's the “proper” way to delete files from a ClearCase snapshot?".
But both process are manual and doesn't scale well.
There are two viable options:
1/ Don't version what is generated (you can re-generate it at any time)
2/ If you must version what is generated, then:
generate it outside of the snapshot view
use clearfsimport to import the result of that generation into the snapshot view: that will checkout the right files and will delete the files that are no longer generated.
That would be the right solution for "w I need a command/script for CC which help me to found ALL removed files"
I have just migrated my code from Perforce to TFS. Everything looks good but there are an issue which is Forward and Reverse integration from one solution to another. This is the show stopper for me.
There are two different solutions and 2 projects are common in both the solutions, but have different copies individually. So forward integration would be merging the whole application from sol1 to sol2 resolving the conflicts in common projects. After it gets resolved merge the code back to solution 1 (reverse integration). Point to be understood is only common projects need to be merged and everything else can be excluded.
Can similar setup be done in TFS?
Yes, this scenario is possible in TFVC, but not very common. You have a few options:
Create a branch root at the solution level and merge the files from solution one to solution two. As part of the merge operation exclude the files you don't want to merge. Later you can merge backwards and forwards at the folder level.
Create a folder relationship, but do not turn the folders into branch roots. This allows you to merge one folder with another folder at any time, but doesn't show these folders as branches per se
Create a branch root at each project level and merge each project individually. This has a couple of drawbacks (as you can't branch the whole solution in this case, as branch roots can't be nested).
Or you can approach the problem differently:
Create a separate solution that contains the common code and use package management (NuGet package publishing) to share the dependencies between both solutions (essentially creating 3 solutions).
Use workspace mappings to keep the common code in a single location in version control and map the code to different locations on disk. You can use compiler directives or configuration or different abstractions (interfaces, abstract classes) in code to compile the sources into different versions.
I got the exact solution which is more or less the first option Jesse you provided. Basically we need to create the common projects for one of the solutions and then branch them in another solution. At a later point in time we can merge them from solution 1 to 2 checkin the merged files in solution 2 and then merge from solution 2 to 1 and checkin the merged files in solution 1.
Ours is a typical implementation of clearcase UCM :
I have 2 UCM projects each of which represent a release for us. proj2 being created from a stable baseline from proj1
proj1 and proj2 work in parallel and sometimes same elements in both get changed simultaneously. So files a.java lies in both projects and is being worked upon by developers at both. A weekly merge activity happens where downstream gets the latest from upstream project and merges are reconciled.This is my easy life.
As a part of restructuring code, team with proj2 has started moving elements (files mostly) to other places. When I say other places this could mean within the component or to a different component VOB. This has never happened before.
The actual problem:
When an inter-project merge happens, the destination branch version of element a.java could have been moved to a different location/folder. How do I ensure clearcase still merges it with the version coming from upstream project. Is using the cleartool move command enough for clearcase to know and merge at the right place ? For inter-VOB movements, will cleartool relocate command do the same for me. I am in a tightly controlled environment else would have created a sandbox and tested it myself.
I am banking #VonC or #Tamir :)
When I say other places this could mean within the component or to a different component VOB
Note that with UCM, you cannot move elements to another component without re-creating completely said element (new history).
-For inter-vob component refactoring:
I would rather mirror the refactoring in proj1 (in a special Stream) and then attempt an inter-project merge from that stream, rather than hoping that a merge from an old directory structure to a new refactored directory structure goes well.
For outer-vob component refactoring (new history)
A manual merge is safer in that case.
Environment
TFS 2010. Three branches: Main, Development and Release.
Question
I would like to easily retrieve a list of changesets that have not been fully merged into all three branches.
For Example
Lets says I have a changeset, 100, that was a bugfix and checked in directly into Release. I can use the Tracking feature to visualize that it exists only in Release.
But that requires me to know to look at that changeset. I'm looking for a generic list that would show me any changeset that exists in one branch, but not in all three.
What I know
I know I can compare Release to Main to see the differences. Is that my only option?
I try to associate changesets with work items, so I could query a list of non-closed work items and then as a 'rule', I could verify that a changeset has been fully merged before closing it. And perform code compare to verify.
From the Developer Command Prompt, you can also use the tf.exe merge command.
tf merge /candidate /recursive Release Main
will show you all the changesets that were made to Release but haven't been merged into Main.
You can get a simple list of changesets through the IDE by choosing the "Selected Changes" option when merging things onto a build.
Another option is to use the API. VersionControlServer has a property named GetMergeCandidates which returns an array of MergeCandidate which has the changeset and if it has been partially merged already as properties.