A few months ago a developer pushed and merged a feature branch into our main branch (develop) that contained test files (800MB). I deleted these files from Bitbucket and everything (it was a pain). Now I am looking for a solution that could prevent this from happening in the future.
Is there some kind of process/script that I could run before performing a merge to my main branch? I would like this process to check every single file in the solution and verify that every file is less than 2.00MB.
Not sure if this will help or not, but the solution consists of various C# projects, including unit tests.
Use one of the git hooks to prevent this, either on receiving a push in the central repo, or before merging.
Related
Seems to be a problem that randomly reappears with no reliability. You can see an example of what this looks like in someone else's code here: https://code.google.com/p/xdpm-toan4/source/browse/trunk/project/GUI/DAO/obj/Debug/DAO.csproj.FileListAbsolute.txt?r=115
A little more info: Project is linked to SVN repo where <<<<<<< .mine would appear in a fresh pull where it did not exist when committed (all of our programmers in the dept. have experienced this). There is never a "theirs" section however those issues would appear in only SVN files. The >>>>>>> .r86 appeared in <filename>csproj.FileListAbsolute.txt after blowing away the .svn folder. Deleting the >>>>>>> .r86 line allows the website to build but without knowing more of what is causing this, I'm hesitant to commit and publish my code.
What might be causing this?
It looks that eventually we moved our project to a bad branching strategy - "Cascading" (in question "TFS -- Sustainability of Cascading Branches" it was recognized viable actually). Now, after reading few articles and seeing it leads to infinite branching tree, I realized that it's bad and want to fix it. But it's not so easy as I expected. TFS allows merges only with parent branches (siblings merge isn't possible).
Here is the diagram of our current branches hierarchy:
Looks weird, but it all started from small changes in latest release branch while trunk has been suspended in the middle of 3-month work. Then we made few internediate releases one based on previous one (up to 1.1.4). But when we started release 1.2.0, the story with trunk repeated and we must have suspend 1.2.0 and implement 1.1.5 hotfix.
Now I faced the need of merging 1.1.5 changes into 1.2.0 branch which isn't possible directly. I can only merge 1.1.5 with 1.1.4 which I wanted to avoid (who knows maybe we'll need to implement 1.1.6 based on 1.1.4 tomorrow). But it seems I have no other way out. Still it will be possible to create 1.1.6 branch from non-latest revision of 1.1.4.
Is it what I must do and isn't there a better way out?
And now comes big troubles and the main question. Eventually I'll need to merge all changes into trunk. And 1.1.5-1.2.0 problem is just a miniature copy of that. That's why I'm asking an optimal and least risky way to perform this merge.
My current plan is the following:
Create branch "1.1.4 final" with the latest stable released version.
Optional: Create similar final branches for all previous numbered releases. Should I do it? Most likely I won't need that versions in the future anymore.
Merge 1.1.5 into 1.1.4
Merge 1.1.4 into 1.2.0. There wasn't much changes in 1.1.5, so I shouldn't run into problems here.
Merge 1.1.4 into 1.1.3, 1.1.2 and downto the release branch. Should I expect conflicts or problems here? I expect and hope not.
Merge release into trunk. Most scary part =)
Stabilize code in trunk.
Now it is time to create a better branching strategy... I'm very unsure about this part at the moment.
Create new "stable" (Main) branch from trunk
Reparent trunk to become child of stable. This solution is suggested in related question "How to fix TFS incorrect branching"
Should I remove current "release" and "R***" branches, or leave them as garbage?
For next comming releases do not create separate branches - instead label the final revisions in stable branch. Actually "stable" branch will consist only of final release checkins.
I'm NOT going to create the "integration" branch for QA of stable features - currently we all live in single active branch without problems.
Create "alternate" branch based on stable for paralel development in case we'll need to once more suspend current work to make some urgent fix. Should I keep single alternate branch forever, or delete it once merged and create a new one (like R125) when again needed?
The idea of this change is to have fixed limited number of branches (ideally 2, at most 3-4).
Please share your thoughts and concerns on my strategy, or propose a better one. I'm asking because not sure it all will work as I expect, don't know if it's the easiest way, and the mistake cost is huge.
Is it what I must do and isn't there a better way out?
I'd carefully perform a baseless merge of all the changes from the branches under release into trunk. I'd do this one branch at a time, and merge "All changes up to a specific version" and select all "Latest Version". That will give you a trunk that contains all of the changes from your releases.
Should I expect conflicts or problems here?
You may get conflicts, but with a bit of care and some forensic investigation of the history, you can get the changes into your trunk.
The normal process when working on release branches (even those not directly related to trunk) is to check into the release branch, then to RI (reverse integration) merge the change back to trunk. Some people prefer to check into trunk first and then merge into the release branch to avoid the situation where trunk may get forgotten about. It's six of one, half a dozen of the other IMO.
Should I remove current "release" and "R***" branches, or leave them as garbage?
I don't think it matters, you could move them into a folder called obsolete releases if you want to hide them, or just delete them - TFS deletes are soft.
Please share your thoughts and concerns on my strategy, or propose a better one
I wouldn't create a stable. Once I had everything in trunk I would be happy, the purpose of a trunk/Main branch is to be the stable releasable version of the code, if the developers cannot keep it that way (I'm not blaming them BTW), then working in feature branches and regularly FI merging into the feature branch is the best way.
Where you go next really depends on the process your company has for releases.
One option is to "label" trunk when you have a release you would like.
Start -----L:R1-----C->
If you then need to put in a bug fix before release, you can branch from the label:
Start -----L:R1-----C->
| /
B:R1 |--C/
Check the change into the R1 branch (B:R1) and merge it back to trunk.
This gives you a branch for releases if needed, but not too deep structure, you may end up with many branches, but you can use folders to keep them organised.
I hope this helps, in closing make sure you read the ALM Rangers branching guide - it covers the main TFVC branching strategies you are likely to need and when you should use them.
And finally, my question to anyone who wants to make a branch is "How will you release this code?", this helps me make branches to solve problems, instead of creating problems. If I don't know how the code will be released, I don't know the best way to structure the branches - I was once involved in a project with a hierarchy of 23 branches off Main, that all ended up coming together before been tested or released - we could have used one :).
Last thing, if you have a VSOnline account or another Team Project Collection, you could try re-creating a simpler version of your problem and experimenting with solutions.
Your merge stratigics looks ok to me but i will try to finish with three branches diagram.
We are using three branches Dev,Test,Release.
most of the builds are from dev and are labeled. (same as trunk at your diagram).
Then we move it to qa and continue development.
If there is an issue \bug and Dev branch is in future development we set test branch to the label and fix the issue on test branch and merge it to dev and again and take label.
If we have an issue with production we use the label on release branch fix the issue, label it and ofcourse merge it to dev.
This how it all done using three branches.
Ofcourse you can always use feature branches for long and defacult features.
Finally, I preformed that merge! Thanks #DaveShaw for recommendations, I mostly used them. But want to publicate my invention which I believe significantly saved time.
Instead of performing a baseless merge from R120 directly into trunk, I created an internediate branch dev, from the common root revision of R120 and trunk and preformed a baseless merge from R120 into dev. That generated more than 600 files with conflicts! But it was easy to resolve them - Take everything from the R120.
Then, since branches dev and trunk have common root, I could merge them with regular merge (not baseless). That performed much-much better than a baseless one and generated only 11 files with conflicts and I could resolve them in only 1 day - all those were real conflicts needing manual resolution and code editing to merge. So that saved me time to distinguish real 11 conflicting files from 600 those which are not a real conflicts and can be resolved automatically.
Next, I will stabilize both branches and switch their roles (it appeared that currently dev plays role of main (stable) and trunk is broken). So I decided to use branching strategy "Development isolation" which will evolve soon to "Development, Feature and Release isolation".
For most of my remaining questions, #DaveShaw provided good explanative answers I have nothing to add to.
I am using svn as source control with AnkhSVN 2 for Visual Studio 2010. Very often I am working on one ticket than switching to work on another ticket without completing first one. Is there any quick way to backup updated files for first ticket? This will simplify coding by managing only related changes.
You could
create a patch file for the svn branch you are working on
then revert your changes
work on new ticket and commit
reapply patch
The question I'd be asking is "Does the software build". If it does, check it in to source control. If it doesn't, get it into a state where it does, and check it in to source control.
You don't have to check into the trunk, you can always have a branch that you use for intermediate code which then gets checked into the trunk when you've completed the tickets.
You should use a feature branch for each ticket, and reintegrate each branch into trunk once finished. Just make sure to read the SVN book to understand the best practices when working with feature branches, and particularly to regularly merge from trunk to the feature branch, before finally reintegrate the feature branch into trunk with the --reintegrate option.
You could also create a patch, save it somewhere, revert everything, then start working on ticket2. But it's fragile: you'll forget where your patches are, lose them, or have a hard time applying them because of conflicts caused by the work on the second ticket. And it's also harder to switch from one ticket to another. Feature branches are the most appropriate solution for this, IMHO.
The problem I'm facing is that it seems that some of the files generated by Visual Studio are not necessary for commits.
Aside from the obvious things not to commit, what other files should I not commit? Do I need to commit .manifest files, etc.?
A different way of saying it: what files are needed to recreate the project I'm working on, and what files can be auto-generated?
Thanks!
The files I usually don't commit are: *.suo and *.user. I commit most other files.
Binary files can be committed or not depending on your company policy. In theory you should be able to recreate them again from the source code, but in practice it is a good idea to have an exact copy of anything you have sent out to a customer. So at least for releases the binaries should be committed.
In general, its a bit difficult to specifically list the files as it depends a lot on what kind of project you have and tools if any you use for autogeneration of code.
In general, the .suo file is something that is user specific and shouldnt be checked in.
However, the easiest way that i can suggest to you is to
Dont checkin any file that you arent sure u need.
Take a copy of all files from your source control into a fresh location.
Build the solution.
If it builds, great. If not, you then add files till it does.
It is a bit trial and error, but most likely its going to be only a one time thing.
Other option is to actually find out for each type of unknown file exactly what it does and then decide whether it is needed or not and accordingly exclude / include.
For this, if you post the extensions of the files you arent sure of, either google / SO can help!!
Personally, i dont believe in commiting binaries at all, even for releases. Seems unnecessary to me as in our case, every release has a label associated with it. So getting the exact code that was released is just a question of getting the code associated with the label and building it.
Also, since deployment is usually via setup files, as long as you have the setup msi / exe (and as long as you are keeping backups of those for your releases) having all the binaries checked in into source control seems a bit of overkill
I have been working for quite sometime to transfer all of the installations for my job from Wise for Windows Installer to WiX. Started with the obvious step (given the number of installations to transfer and their size) and decompiled them with Dark.exe (WiX toolkit). I have been creating a general purpose program to clean up the output from dark into a proper project that we can then compile into MSI's. The problem that has been kicking my #$$ for some time now is the merge modules. We have a maximum of 20 Microsoft MSM's in the various installations, and dark doesn't recongnize these as such so instead lists all the contents. I have everything in place so I can erase this garbage code and replace it with the proper Merge tag. Hence the problem. The merge modules don't have any rhyme or reason to where they are placed, no logic I can find to look for the main folder. The only real common ground is that the Directories, Components, Files, and Registry tags all have an Id ending with a GUID. Any ideas would be greatly appreciated. I already have the frame work in place to search through our list of Merge Modules and retreive the list of files, components, and directories. I just don't know what to look for so it is not speciallized to just one or two modules, but in theory all MICROSOFT modules (I know other companies might use other formats, but that is a mute issue). Thanks again!
It looks like you have been doing a lot of work reverse engineering the existing MSI's and cleaning up the result in an automated or semi-automated way.
Wouldn't it be more efficient and less error-prone to just create the wix source files from scratch? You might be able to leverage the heat.exe tool to reduce the required effort.