My co-worker is trying to merge his development branch back into the baseline. Even though he only modified a couple files, all files in the baseline are being checked out for merging. As if it's a baseless merge. What gives?
I don't experience this and the only difference I can see is that I branched directly from the baseline and he made a branch and then did a "move" on the branch. Does moving a branch mess up the link back to the baseline? He is still able to select the baseline in the GUI so I don't think it's doing a baseless merge since that's only available via command line, but it's behaving like that.
Anyone got some insight or know what else we should check?
This is by design. TFS needs to mark the changeset where you moved the source branch as "already accounted for" so it's no longer a candidate next time you merge.
Merge history is recorded at Checkin time by updating all of the pending changes that have their Merge bit set. Ordinarily, this is accompanied by other change types like Edit, Delete, etc. If not, it's just a recordkeeping transaction like the case you've encountered. (there are other cases) No files will be modified by checking in the "no-op" merges.
Related
I am not sure if I can do anything about this and it is not a huge hardship to leave it as it is.
I did try to fix things by following steps on other SO topics etc. and ended up loosing all my help revision commits and files.
Things are a little messy and I will try to explain. The history is OK up to a certain point:
Removing unused resource ID values from resource.h
Can you see that towards the bottom of the screenshot of the log?
Since that time, the majority of the commits are help file revisions:
Deleting help topics and redundant images
Revising help topics and images
Adding new help topics and images
But it gets complicated because with that big chunk of help revision commits I have some code change commits. Eg:
Added SetLoggingPath to CMSATools.
Revised CChristianLifeMinistryUtils::FillStudentsListBox method. Now it reads the students from the publishers database.
The plot thickens, for a small handful of them, eg:
Add Help menu to CPublishersDatabaseDlg.
In those cases the commit is a combination of code changes and help revision changes:
Added OnHelpHelp menu handler.
Started writing Help/HelpPublisherDatabase.html help topic.
The primary issue:
Beginning at this commit in the master branch: Removing unused resource ID values from resource.h can I make a new feature branch called: help-revisions and then, move the commits from master to the feature branch?
If it is possible, I am assuming we would need to move just the commits that are purely help revisions. I am not sure how to handle the commits that are a mixture of help changes and code changes.
So, ideally I am hoping to split out all the help revisions into a feature branch so that it can be merged in to the master and look better in the log. Leaving the code tweak commits alone in the master in an appropriate position.
The related matter is the cause of some of this. But I am not going to discuss that here after all.
As mentioned, I am just curious as to know if it is possible to improve the history I have as indicated.
I am a lone developer so do not have to worry about other individuals repositories.
Thanks for your help and time.
Update
I have given the rebase a go. I marked all the commits I wanted to split as edit. Then I started the rebase. I ticked edit/split and revised them as I needed until it completed.
Now my log looks like this:
Underneath, it looks like this:
So how do I get rid of that section? I have to fix that before I create the feature branch and do the cherry picking.
So, at the top I now have a new set of all the commits including the split ones.
Got it - did a force push of master branch.
This can be accomplished by a mixture of cherry-picking and rebasing.
Create a new feature branch which is before all your commits which are affected. Then select all commits you want to have on that new feature branch and select "Cherry-pick commits". After that you have a branch where only the selected commits are on.
Switch back to the previous branch and do a rebase on the parent of the newly created branch (you will need to enabled "force"). Now mark all cherry-picked commits again and select skip and start the rebase. Now, this branch does not contain the cherry-picked branches any more.
I know I can do a "compare" between two changesets and get a list of the changes made in the period of time between the changesets in question.
However, from that list I would like to exclude all changes that are the result of merge operations only (change types merge; merge, edit; merge, branch; etc.).
My goal is to get a list of what changes (edits, adds, deletes, ...) have been made within the particular branch, including to any files which have also had changes merged into the branch from other branches, without cluttering up the list with changes made in other branches and simply merged into my branch of interest.
How do I do that?
Getting a list of changes to a particular branch is quite easy. In source control, just press Ctrl-G. You can then filter on the branch and get a list of changes, and you can specify the change sets; then select Find. This will include merges though.
This may not completely solve your issue, but it will help I guess.
If you know about the source branches which would have merged to your branch then you can make use of the TF MERGES COMMAND which will give you the changeset numbers on when the merges happened.
I was about to commit about 1000 files at once after few refactoring stuff. Is it advisable to commit such huge number of files or I should commit them in batches. I am trying to look at pros and cons sort of.
One of the pros is that I will have same entry in the SVN for all my changes and will be easy to navigate.
With a number of files as small as 1000, I would worry less about performance and more about correct work flow. 1000 files is a lot of files and thus a lot of changes, but Subversion should handle it reasonably well.
However, if all of the changes are not actually 1 change, then it should not be one commit. For example, if you're renaming 3 functions, I would make each rename a separate commit. Depending on what specifically you're doing, you may be able to get away with one commit, but a year from now when you're browsing through the logs, you'll make life easier on yourself if you tend to stick to small commits. If it really is only one change, then one commit is definitely your best option (for example, renaming one function).
SVN can handle 1000 files at once. The only reason to check in batches is to give each batch a different commit message, like "fixed bug #22" and "added flair".
the number of files doesnt really matter.
when you commit changes to your code repo, you should be thinking of build statiblity and test compliance.
That answers your question: If you have made changes to n files and only commit some of them, then you're likely to break the build (not even talking abt the tests). So you should commit all necessary files to guarantee build integrity at least.
svn and other tools are well capable of dealing with such nb of files, which will represent a single transaction on the server.
In this article, the author explains rebasing with this diagram:
Rebase: If you have not yet published your
branch, or have clearly communicated
that others should not base their work
on it, you have an alternative. You
can rebase your branch, where instead
of merging, your commit is replaced by
another commit with a different
parent, and your branch is moved
there.
while a normal merge would have looked like this:
So, if you rebase, you are just losing a history state (which would be garbage collected sometime in the future). So, why would someone want to do a rebase at all? What am I missing here?
There are variety of situations in which you might want to rebase.
You develop a few parts of a feature on separate branches, then realize they're in reality a linear progression of ideas. Rebase them into that configuration.
You fork a topic from the wrong place. Maybe it's too early (you need something from later), maybe it's too late (it actually applies to previous versions as well). Move it to the right place. The "too late" case actually can't be fixed by a merge, so rebase is critical.
You want to test the interaction of a branch with another branch, but for some reason don't want to merge. For example, you might want to see what conflicts crop up commit-by-commit, instead of all at once.
The general theme here is that excessive merging clutters up the history, and rebasing is a way to avoid it if you didn't get your branch/merge plan right at first. Too many merges can make it hard for a human to follow the history, and also can make it harder to use tools like git-bisect.
There are also all the many cases which prompt an interactive rebase:
Multiple commits should've been one commit.
A commit (not the current one) should've been multiple commits.
A commit (not the current one) had a mistake in it or its message.
A commit (not the current one) should be removed.
Commits should be reordered (e.g. to flow more logically).
While it's true that you "lose history" doing these things, the reality is that you want to only publish clean work. If something is still unpublished, it's okay to rebase it in order to transform it to the way you should have committed it. This means that the final version in the public repository will be logical and easy to follow, not preserving any of the hiccups a developer had along the way.
Rebasing allows you to pick up merges in the proper order. The theory behind merging means you shouldn't have to worry about that. The reality of resolving complicated conflicts gets easier if you rebase, then merge new changes in order.
You might want to read up on Bunny Hopping
Here is my use case:
I start on a project XYZ, for which I create a work item, and I make frequent check-ins, easily 10-20 in total. ALL of the code changes will be code-read and code-reviewed.
The change sets are not consecutive - other people check-in in-between my changes, although they are very unlikely to touch the exact same files.
So ... at the end of the project I am interested in a "total diff" - as if there was a single check-in by me to complete the entire project. In theory this is computable. From the list of change sets associated with the work item, you get the list of all files that were affected. Then, the algorithm can aggregate individual diffs over each file and combine them into one. It is possible that a pure total diff is uncomputable due to the fact that someone else renamed files, or changed stuff around very closely, or in the same functions as me. I that case ... I suppose a total diff can include those changes by non-me as well, and warn me about the fact.
I would find this very useful, but I do not know how to do t in practice. Can Visual Studio 2008/2010 (and/or TFS server) do it? Are there other source control systems capable of doing this?
Thanks.
You can certainly compute the 'total diff' yourself - make a branch of the project from the revision just prior to your first commit, then merge all your changesets into it.
I don't think this really is a computable thing in the general case - only contiguous changesets can be merged automatically like this. Saying it's 'unlikely' for others to have touched the files you're working on in the interleving commits doesn't cut it, you need guarantees to be able to automate this sort of thing.
You should be working on a branch of your own if you want to be able to do this easily.
The ability to generate diff information for display or for merge purposes is functionality provided by your version control system, as Mahesh Velaga commented on another answer. If you were able to compute the diff by cherry-picking non-contiguous changesets, then logically you would also be able to merge those changes in a single operation. But this is not supported by TFS. So I strongly suspect that the construction of the cherry-picked diff information is also not supported by TFS. Other version control systems (git, mercurial, darcs come to mind) might have more support for something like this; I don't know for sure.
From my reading of their answers on the TFS version control forums, I think that their recommendation for this would be to create a branch of your own for doing this work in the first place: then the changesets would be contiguous on that branch and creating the "total diff" would be trivial. Since it sounds like you are working on an independent feature anyway (otherwise a diff of only your changes would be meaningless), you should consider having an independent branch for it regardless of whether your version control system is TFS or something else.
The alternative is to construct what such a branch would have looked like after the fact, which is essentially what Jim T's answer proposes. You might prefer that approach if your team is very keen on everyone working in the same kitchen, as it were. But as you are already aware, things can get messy that way.
Create two workspaces. Get Specific Version for files specifying the date or upto those two changeset on those two workspace. Now compare folders using a compare tool. Araxis merge is best one.
sounds like you need a tool that supports changesets (changes over multiple files and committing them all at once) instead of committing each file alone
take a look at this comparison between sourcesafe and mercurial ( free and you can find tools to integrate it with visual studio )