This is what I am trying to do in TFS (a trivial operation in CVS)
Statements:
There are 2 independent code trees in TFS, corresponding to:
HEAD development
STABLE version.
Something like this:
$/MyProduct/HEAD/<files>
$/MyProduct/STABLE/<files>
I have a few changes in HEAD that I need to backport into STABLE.
The changes are represented in a ChangeSet
Does you know if it is possible to do the following operation in TFS:
Create a patch file from a TFS changeset number, which is based on the HEAD tree
Apply the patch in a different TFS tree, in case STABLE
Have the merge tool to merge the difference.
What I have now is a bunch of scripts that work outside TFS - but it would be much better to have this feature inside TFS.
This list seems to discuss this, Apply specific changeset from one TFS instance to another - But what it basically says is that there is NOT an internal way of doing my operation.
I wonder if someone know some other secret.
The way to do this in TFS is to use branches. HEAD and STABLE should both be branches with a branch relationship in place. Then you can simply merge from HEAD to STABLE whenever you desire, and the VS merge tool will help you with the merging.
If you don't have this setup as branches you should do this ASAP. What I would do is backup the files in HEAD somewhere on your local disk. Then delete the HEAD folder in TFS (and locally). Make STABLE a branch, then branch off of STABLE to create HEAD. Now HEAD is a branch with a relationship to the STABLE branch.
Then in your local workspace overwrite the files in the HEAD folder with the ones you backed up previously. So long as you are using VS 2012+ you can use the Local Workspace functionality, and VS will detect all the changes and allow you to check them into HEAD.
From this point on you can merge HEAD into STABLE whenever you wish.
Related
I want to use Mercurial for a email-based sync system (see this question).
I have played around with sending bundles back and forth ad applying them to the repositories to be synced. But I often get merge conflicts which I have to resolve manually.
But they could be resolved easily automatically: I just want the newer file to replace the older one.
Is it possible to set up a merge-tool in Mercurial that does exactly that: When I hg pull a bundle it updates to the file with the newer time stamp?
When you pull or unbundle new changesets in repository must not intersect with done in parallel (you'll get new head only) - I can't see why you can have merge on pull (uncommited local changes? Commit before pull!)
If your merge-conflicts appear on merge heads (when you merge local head into tip after pull) and you prefer to have tip version of conflicted files and abandon local changes you can use merge with --tool=internal:local option
If you prefer dummy-merge, i.e abandon all local changes from all files, you can use this trick from Mercurial wiki
We migrated from a different source control system. The latest files from each branch were checked in to folders in TFS 2010 source control, and we used the "convert to branch" command on each top-level branch folder. Since the initial checkins, work has been done on the trunk and the branches.
However, we can't do merges from the GUI because TFS does not understand the relationships between the branches. The "reparent" command does not offer any options. Is there a way to use tf merge /baseless /discard /recursive to set up the relationships? Will this cause problems since there have been checkins after the initial ones?
I've just spent the last 6 months migrating 100 or so VSS repositories in to TFS so I feel your pain! I've only done this in TFS 2008 but there is no reason why it shouldn't work in 2010.
I would treat a baseless merge as a last resort as you'll be stuck doing merges from the command line.
The trick is to establish the relationship between the branches before you import your code.
(I'll use a simple single dev branch as an example but you should be able to use the same theory regardless of the number of branches)
Create a new team project, create your "trunk" then branch to "dev". You should now have two empty branches.
Import your code in to "trunk" and "dev".
Merge from "trunk" to "dev", you will almost certainly have lots of conflicts, TFS should be clever enough to ignore files and folders that are the same, but not always. You will need to decide which of the conflicting files you want to keep (usually the ones in the "dev" branch but you probably want to have someone who understands the code near at hand to make the decision)
Now you should have 2 branches full of code that have a relationship.
If you have multiple "dev" branches then I think you should always merge from "trunk" to "dev" first, this sets up the relationship and gives you the option of keeping the version of the code in "dev" as this is probably more recent that the version in "trunk"
In your specific case I would follow the above but instead of importing your files (step 2) from the file system, you could branch the code from your "old" team project in to the new one i.e.
branch $/oldTeamProject/Devbranch in to $/NewTeamProject/DevBranch and $/oldTeamProject/Trunk in to $/NewTeamProject/Trunk
then merge $/NewTeamProject/Trunk in to $/NewTeamProject/DevBranch
I've done this a couple of times in TFS 2008 and it works like a charm (except the pain of doing the initial conflict resolution). Having said that I would recommend doing a "test" migration, just to make sure you've covered all of the angles. If this works ok then you can keep the result, if not you should have learnt some lessons for the real migration :-)
If you've renamed any files or folders then TFS won't know to establish the relationship and you'll get duplication in your "dev" branch after the merge. You'll have the same issue if you do a baseless merge at the folder level. There isn't an easy way around this I'm afraid. you just need to keep an eye out for anything that look slike it's been renamed and manually resolve them after the merge.
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
Keep track of history on my own features
Have fixes and improvements from the main tree easily incorporated in my new-feature fork
Easily apply my own bug-fixes to my new-feature fork
Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands like cvs diff if you need to).
We have a folder structure in our source control where some things are branched, and some aren't.
The branched stuff follows a (standard?) pattern of Production, Main, Development branches plus the occasional branch for a large project.
Sometimes as part of those large projects web branch some of the stuff that is normally not branched. For instance we might branch $/source/Libraries/LibraryA into $/source/branches/Project1/LibraryA to make some major Project1-related changes to it.
Then when Project1 is nearing release, we reverse integrate both from Project1 into the Main branch, and from Project1/LibraryA into the Libraries folder.
Well, that's how we did it in TFS2008. Recently we moved to TFS2010 which seems to keep track of what things are branches and what aren't. So when we try to branch LibraryA as a subfolder of Project1, we get and error message that Project1 is already a branch.
Is there a way around this? Are we using TFS2010 wrong, and if so, what would be the right way?
As I detailed in "Team Foundation Server and branching characteristics, compared to others", the branching model of TFS has evolved quite a bit between TFS2008 and TFS2010.
The TFS Branching Guide and Branching Guidance can help.
See this thread for more details on branch management:
In TFS 2010, a user must have Manage Branch permission set to Allow for a given path to do the following:
Convert folders to branches (and branches back to folders)
Update metadata for a branch (i.e. owner, description)
Create additional child branches from the original branch
Change the relationships between branches with merge relationships (i.e. reparenting branches)
W In TFS 2010, a user must have Merge permission set to Allow for a given path can do the following:
Pend merge operations on branches, folders, and files under the specified path
Manage Branch and Merge permissions are new for TFS 2010.
Branching in TFS 2010 is a server-side operation.
Presumably, if you have a team of developers and you grant them check-in and check-out permissions without merge or manage branch permissions - these developers would be able to create workspaces that map whatever branches they need to work on to local folders on their hard drive.
In VS 2010, Branches are now a first-class object and as such have a branch icon that easily distinguishes a branch from a folder (with a folder icon).
See also this thread with a scenario closer to your situation.
For shared libraries, I generally prefer using file references rather than project references.
I would have a separate TeamProject for developing the source code for these libraries.
You could deploy the assemblies to a shared folder and reference these assemblies from the various projects that use them.
This approach would permit you to have multiple versions of the assemblies. Each project would create file references to the particular version they require.
I had similar issue. I was trying to create another branch in DEV (in separate folder) from MAIN and this error popped up.
What resolved this problem for me was to create a new branch in the root and later move it to Dev.
I'm using TFS and trying to merge a branch back to the trunk from which it was made. Trouble is, the Source Control Merge Wizard has no entries in its Target Branch dropdown list.
I suspect this is because the trunk was renamed after the branch was made. Is there a simple way that I can still perform the merge and have TFS recognise that the two branches are actually related?
I know very little about baseless merges, but is this the sort of thing they're used for?
You might have to use the TF command-line utility. There are some features of TFS (even in 2008) that are only available from the command line. See the merge command.
I have not tried this, and TFS under 2005 was not particularly stable IMHO. (It got much better after 2008 and SP1.) I would recommend replicating the scenario (branching, renaming the trunk, merging from the command line) in a test environment or on a non-critical branch first.
I also haven't tried baseless merges. This article makes it sound similar to what you're doing, but also says that you have to use the TF command. I would think (hope) that there would still be a relationship between the branches after you renamed the trunk, though.