Recently I did changes in makefile to optimize my feature build time. Though it reduced my feature build time but impacted the total build time (2 hrs 30 mins to 6 hrs :( ). I compared the emake conflicts results of both the builds (my changes and prior one). Mine is having the 2k conflicts. But the prior one is 62 only. But when I compare the build logs all the data seems to be same. Where am I making the mistakes? Please share your inputs. Thanks in Advance.
Krishna
It is all based on the dependency information you have it in history file. I had the same problem in my build system where make built it fast where emake was sluggish for the same build scripts.
The solution to this issue to generate history file first time by running slow build. emake will generate history file at end of the build. Use this history file which will make your build faster.
emake --history=
Related
I'm not new, but still struggling with git. in particular merge vs. rebase. the current result is that when i go to github.com to look at my feature branch (last commit) , it tells me that 152 files were changed, with 6,099 additions.... I'd estimate more like 30 files. And indeed, the changes shown are certainly not mine.
It has, admittedly, been a long-running branch (4 weeks or so) but I keep updating it with the develop branch that the team uses. Sometimes I need to make conflict commits, but not this many.
Before I do a pull request, any thoughts on what i did wrong would be appreciated.
I faced similar issues many times. I would suggest to raise a PR and in files changed tab it will only show your changes. I have had similar problem but it works perfect when you raise a PR.
I would git ignore all of the self generating files in the project. gitignore
Just make sure that all files you do this with can be deleted from the project and the project would just remake them without causing issues.
I'm working on a big Solution, which includes 20 projects(in silverlight, and use 10 wcf sevices), each tim to test presentation layer, I have to Build all Solution, and it take much more time.
do you have the solution to reduce the build time?
Go to Build/Configuration Manager... and uncheck the projects
that you are not working on. This way you only build the relevant
project.
Create a solution which only include project that you wish to modify. Copy the DLLs from other projects into a folder. Go to Build, Your_Project Properties... Reference Path, and add that folder.
Switch to parallel MSBuild (by adding external tool), which can utilize all your CPU cores. Set arguments to multiproc and verbosity - minimal:
/m /v:m
Get rid of unused styles
Use SSD
If you're on a laptop, make sure your machine is set in high performance mode.
Also refer to my old blog post
We have constant problem with project XML file (*.sqlproj). If the files are added/renoved/changed location then it automatically adds/removes records in some unexpected places. After that we have big troubles by merging it when somebody changes that file also.
We came to conclusion that we might sort it before checkin. We would alphabetically sort it and in that case merge tool will understand it much better.
So, my questions would be:
Is it possible to re-arrange sqlproj file somehow before EVERY check-in? Maybe there are somekind of options/tools that doing that already?
Are there any other ways to make developers life easier?
UPDATE:
Once again I got the same problem. sqlproj file was modified 3 times and I want to merge to production only the last change, other 2 are not tested yet. in the merge tool I have the option to add all these 3 new objects or leave it without changes. I am not able to select only the last change ...
EXAMPLE:
developerA created tableA and checked in;
developerB got the latest version of dev branch, created tableB and checked in;
developerC got the latest version of dev branch, created tableC and checked in. DeveloperC tested the code and ready to go to production. He tries to merge his code to QA and get's the conflict where he has an option only to go with ALL changes.
I understand the scenario you are running into very well. This typically happens when you have multiple work streams happening in the context of a single repository and you don't have a common promotion schedule (as in all work will go to QA at the same time and PROD at the same time).
There's a few ways I can think to get around this problem and there are pros and cons to each option.
Lock each environment until everything can promote together. Not realistic in most cases.
When you are ready to promote, create a promotion branch from source environment and take things out of the promotion branch that aren't ready to promote to destination environment. This allows devs to keep working and be able to promote without freezing.
Hybrid approach... Don't source control anything in Dev until it's ready to promote to test. Then either do option #1 or 2 from there onward.
Create a more flexible ecosystem that can spin up an environment for each Feature branch in order to demo/test with others(or at least allocate/rotate enough between the developers to accomplish the same objective). Once it's accepted promote. This is what we are working towards currently but building out the infrastructure and process when you have a ton of interconnected databases and apps that share them is a bit challenging to say the least (especially in the Microsoft world).
Anyways hopes this helps...
1 - what source control are you using? No source control that I am aware of understands the context of sqlproj files but this isn't normally a problem.
2.a - This shouldn't be a problem you get constantly, are you checking in/out regularly? I would only expect to see issues if different developers are making large scale changes to the projects and not checking out / checking in before and after.
2.b - It is also possible you are not merging correctly, if you take both both sets of changes then it is normally fine.
ed
I’ve just updated most of my static files but it seems that the old versions of those files are still being served. How long does it usually take for the new versions to be served? Is there any ways to speed that up?
Are you talking on production server?
In my project, usually they are affected immediately. Sometime due to the caching framework ,it keeps old static file served. I'm using Django-nonrel.
If you are using Google Chrome, you can you Inspect Element to see if it has an cache-control header or not.
Also this link will help you to change default_expiration on app engine.
Maybe it gives you some clues
I've found that it's usually immediate but sometimes takes about 15 minutes or so. For css/js many people append a build # to the filenames to break the cache.
I have been struggling with versioning software for a while now.
I'm not talking about a naming convention, I'm talking about how to actually apply a version in a build system all the way through to a release.
I generally use major.minor.maintenance-[release type]
i.e. 1.0.2-rc1
The problem is managing the version number. I've tried many ways (sticking it in a build file, a properties file, a database, etc,etc) but I haven't found anything that really works well.
The closest thing I came up with is using Jira which I documented here:
http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
I'm wondering if anyone has any good ideas about this.
Also, wondering how people handle releasing a version.... i.e. If I release/deploy version 1.0.0-rc1 do bugs found in this release then get logged into 1.0.0 (the next/production release).
Microsoft uses <major>.<minor>.<patch>-<build number> (or a variation).
I like using <major>.<minor>.<buildnumber>
Where I'm working we use the Maven system: artifact[-major-minor-revision][-SNAPSHOT] which allows us to develop "in progress" versions that change at a moments notice (SNAPSHOT) and those which have been formally released. Some examples are:
email-services-1.0.0-SNAPSHOT.jar
email-web-2.3.11.war
crm-2.5.0.ear
If it has SNAPSHOT in it then it hasn't passed the full suite of tests or is just a developer experiment. If it doesn't have SNAPSHOT then it is a release candidate. We maintain a repository of release candidates and the most recent is sent for deployment once the testers are happy with it.
All of this can be managed with a few simple entries in a build file under Maven. See Maven2 tutorial
This is probably a dead post now, but I'll add my two cents anyways. I'm of the opinion that build numbers should mean something to everyone who sees it. So I personally think that this is a good way to name versions:
major.minor.patch.revision - e.g. 1.1.4.2342
Major/minor numbers are pretty self-explanatory. But from the perspective of the 3rd number, it still needs to mean something to the customer. I've released this new version to you, Mr. Customer, but it wasn't worth a new minor number since we just fixed some bugs. So we've incremented the patch number.
The 4th number usually means absolutely NOTHING to the customer, so you might as well make it useful to you and anyone else in your company that sees it. So for us, that number is the SVN revision number. It tells us exactly which revision was responsible for that version so that we can pull it out any any time to recreate it. Branching code obviously achieves this too, but not to 100% certainty.
Also, another advantage with an all-numeric version number is that it easily integrates into nearly every continuous build system.
Anyways, that's my two cents.
+1 on the Jira/Bamboo solution. The only additional information about the build I would include (for my purposes) is the Subversion Release, although the Tagging operation is 80% of what I want.
Manually maintaining the release/version information is a royal pain. Letting JIRA drive it is a great idea.
On the final question, about where bugs/defects get logged and releasing a version:
Defect/Issue is logged against the release where it appears. A defect in 1.0.0-rc1 gets logged against 1.0.0-rc1
JIRA has (or maybe we added) a 'Fix-For' field that would have the planned release, in this case 1.0.0
If the defect/issue is severe enough, it may be necessary to add another 'rc' release.
The release is made when there are no outstanding critical defects/issues and the customer (or management) agrees that any remaining issues can be deferred
The beauty of managing this through JIRA is that adding releases, generating change-logs, etc. is automated fairly well.
We also use <major>.<minor>.<buildnumber> and we manage this with CruiseControl/(.Net) on our build server. And use Wix and CruiseControl Config to manage the Major minor numbers - still increment those by hand - but the build number happens automatically when on the build server. You could set up a rule an increment the major/minor automatically too I believe - we just have like to do that manually so that it takes concious thinking by a dev when it is time to name a particular release level.
Major.Minor.BuildDateNumber.DailyBuildNumber
Major and Minor are set by us, manually incrementing them as we see fit.
BuildDateNumber is the number of months since the project start multiplied by 100, plus the day number of the current month.
DailyBuildNumber is incremented for every build after midnight each day, starting at zero.
E.g. 4th build of release 5.2 on 10 July, where the project started 1 Jan that year, would have version number
5.2.710.3
This is all calculated for us by the Version task in Nant.
This keeps the version numbers unique and also allows us to quickly calculate when an installation was built.