I have a question, is it possible for TFS2008 to be able to create a build by extracting files from a specific label? Lets say there are three labels within a branch and I would like to build only modified files from L2 to Latest so the build output drop folder only contains the items that were modified between L2 and Latest labels, is that possible?
Thanks.
No, I'm pretty sure you can't do that. Maybe you could build a custom build process template to do it or something.
Related
This issue describes the concept
https://github.com/dart-lang/source_gen/issues/272
To summarize:
I am using source_gen to generate some dart code.
I am using json_serializable on the generated dart code.
I wish to output all of the results to a source directory adjacent or below my target source.
The desired directory structure
src
feature_a
model.dart
gen
model.g.dart
model.g.g.dart
feature_b
...
I have considered building to cache however it seems json_serializable doesn't support this and even if it did I don't know if its even possible to run a builder on files in the cache.
I've also considered an aggregated builder that is mentioned here.
Generate one file for a list of parsed files using source_gen in dart
But json_serializable is still an issue and the source_gen version in that post is super old and doesn't describe the solution well.
This is not possible with build_runner. The issue to follow is https://github.com/dart-lang/build/issues/1689
Note that this doesn't help much with builders that you don't author, and wouldn't work with things like SharedPartBuilder.
This question have been asked numerous times, but I have not managed to get an answer that I am happy with. Probably because the most answers is of "how do I do this?" type and also get "this way you do this" answers.
The problem I have is that I need to use absolute paths when I want to reference to images in Xcode (version 6.0.1). I am quite sure that I could place the images in my working directory which is something like:
/Users/patrikek/Library/Developer/Xcode/DerivedData/ChessGame-
ftpbqerfsenxxbfvneyzfwdmtwjk/Build/Products/Debug
Then add the file to some Xcode group in project navigator (eg. images/myImg.png) and I would be able to reference the file as myImg.png (since I have not foldered the image inside my working directory). I am also quite sure that the project navigator stuff would not b required for this to work.
And after this introduction comes the questions:
1) Is it necessary to place all images and other resources in the current working directory? Also, if not what is the best way to store folders in a program and is it necessary to name the folder containing images to Resources?
2) Is it possible to arrange files using the project navigator? What I am after is to use the project navigator only and let Xcode worry about the details of copying files and so. It seems somehow unnecessary to have a project navigator, when the physical files are not packaged in the same way. It does also seem error prone to update the project navigator and the physical hierarchy independently of each other.
An example:
I create a folder images in the Project navigator, inside that folder am I placing a reference to the image using the usual way in the project navigator. Is it now possible to make Xcode arrange so that I can do a call images/myImg.png when I want to load the image in some function (without me doing anything, since if I move many images to my working directory I may forget one and I may also spell images wrong by mistake if I create another folder in my working space). Also what have happened inside Xcode when this action was done?
Since I am not at all familiar with Xcode yet I may have got something wrong here, but the core of this problem is to find out where the files physical location must/should be and if there is some way to let Xcode do this by using the project navigator.
BR Patrik
Xcode does not manage images the way you have presumed that it does. Take a look at the 2013 WWDC "What's New in Xcode" video to see how Xcode 5 and Xcode 6 organize and manage images for any given project. When you have configured the asset catalogues for your project correctly, it wouldn't matter where the original images live on disk. As long as you have dragged the right assets into the right catalogues, your projects will work. The good news is that you only need to configure images once and change only the ones that change once done. For details, see this wwdc video: http://devstreaming.apple.com/videos/wwdc/2013/400xex2xbskwa5bkxr17zihju9uf/400/ref.mov
Once an image is configured in the asset catalogue, you can refer to it with or without it's file extension. For example, you can refer to "example.png" as "example" in your code. Hence, "myImg.png" can be "myImg" or "myImg.png" in code. No need to worry about which subdirectory contains it.
Now if your question has to do with runtime assets, again your development system directory structure would not matter. If that is the case, then you might have to re-ask your question. I would be glad to help you there as well--if that's what you want to know.
Is it possible to color each line of hg log output based on the individual changeset's content and/or description? For instance, I'd like to help the "real" work stand out, by graying out the lines for merges and the lines for changes that only touch testing resources (no programming language files.)
Based on our teams habits, I could get roughly what I want by looking for the words "baseline" and "merge" in the descriptions, but file patterns and directories (for baselines) and topology (for merges) would be more precise.
Is there a way to configure hg to format each line differently?
I don't think it's possible to color only based on the content but you could use Mercurial revsets (hg help revset) to display only the relevant changesets.
Something like: hg log -r "not desc('merge') and not file('test/*')" should get you on right track.
Here are some details how it works:
desc('merge') will select changesets containing merge in their description.
not desc('merge') will filter out such changesets.
file('test/*') will select changesets touching files in the tests directory.
not file('test/*') will filter out such changesets.
The big problem with this solution is that it would filter out changesets touching files in both the test directory and somewhere else, I'm not sure there is a dedicated revset for that.
I have a simple build definition which I want to use to build just one project, and every time I choose to run this build, I want to get latest from the branch/directories that pertain only to the project in question. How do I do that? The call to "Get Workspace" gets everything from source control, and I do not want to (or need to, for that matter) get latest from everything for various reasons.
I hope I am not asking for much.
Thanks in advance.
Check the workspace mapping in the build definition. The build only gets the items that you have specified over there. If you want to exclude some folders within the path that you are mapping, you can choose to cloak some folders.
You can adjust your ItemsToBuild in Process Tab in Required section
I'm using Mercurial for development of quite a large C++ project which takes about 30 minutes to get built from the scratch(while incremental builds are very quick).
I'm usually trying to implement each new feature in the new branch(using "hg clone") and I may have several new features developed during the day and it's quickly getting very boring to wait for the new feature branch to get built.
Are there any recipes to somehow re-use object files from other already built branches?
P.S. in git there are named branches within the same repository which make re-usage of the existing object files possible for the build system, however I prefer the simpler Mercurial separate branches model...
I suggest using ccache as a way to speed up compilation of (mostly) the same code tree. The way it works is as following:
You define a place to be used as the cache (and the maximum cache size) by using the CCACHE_DIR environment variable
Your compiler should be set to ccache ${CC} or ccache ${CXX}
ccache takes the output of ${CC} -E and the compilation flags and uses that as a base for its hash. As long as the compiler flags, source file and the headers are all unchanged, the object file will be taken from cache, saving valuable compilation time.
Note that this method speeds up compilation of any source file that eventually produces the same hash. If you share source files across projects, ccache will handle them as well.
If you already use distcc and wish to use it with ccache, set the CCACHE_PREFIX environment variable to distcc.
Using ccache sped up our source tree compilation around tenfold.
A simple way to speed up your builds could be to use a local "build directory" on your disk. This way you can checkout into this directory and start the build. The first time it will take the full time, but after that it will (hopefully) only rebuild the files where the source code changed.
My Localbranch extension was designed partly around this use case. It uses a single working directory, but I think it's simpler than git. It's essentially a mechanism for maintaining multiple repository clones under one working directory, where only one is active at a given time.
Woops, I missed your P.S. where you don't like having multiple named branches in the same repo and that you prefer separate clones.. sorry about that.
I too have somewhat large C++ projects and the clone-per-feature workflow didn't work for me very well. Firstly, I had to close down my Vim session and then reopen (many of the same) files once I've created the clone. Secondly, like you said, a lot of code must be recompiled unnecessarily. Thirdly, I have to keep track of where I've pushed to and pulled from - gets confusing when you start a new feature and then get sidetracked onto a new one. Before you know it you have many clones and not sure which ones need to be pushed back to your main.
You definitely don't want to use named branches (as I'm sure you know) to handle this as they are quite permanent.
What you need are bookmarks: https://www.mercurial-scm.org/wiki/BookmarksExtension
Bookmarks allow you to create lightweight (and otherwise anonymous) branches per feature by facilitating the naming of heads in your repo. These heads would normally be unnamed and you would have to look at the output of 'hg log' or use some graphical tool to find the revision numbers for the tip of your feature-branch. With bookmarks you can name them descriptive names like 'my-cool-feature' or 'bugfix-392'.
If you like the idea of bookmarks, I'd also recommend my own extension called 'tasks': http://bitbucket.org/alu/hgtasks. This extension works like bookmarks but adds some more functionality. It allows you created feature-branches (now called tasks) and suppress the pushing of incomplete tasks. This is handy when you have a few feature-branches at once. You may not be ready to push your 'my-cool-feature' task, but 'bugfix-392' is ready to go. Because tasks track a set of changesets (and not just one 'tip' changeset) there are some things you can do with tasks that you can't with bookmarks. See an example workflow here: http://x.zpuppet.org/2009/03/09/mercurial-tasks-extension/.
Mercurial also has local named branches, see the hg branch command.
If you insist on using hg clone to do branchy development, I guess you could try creating a folder link (shortcut under windows) in your repo to a shared obj folder. This will work with hg clone, but I'm not sure your build tool will pick it up.
Otherwise, you probably keep all your repos in one folder - just put your obj folder there (it shouldn't be under source control anyways, imo). Use relative paths to refer to it.
A word of warning: many .o symbol tables (or equivalent) contain the full path name of the source file. If that other file changes (or if the path is not visible from the new directory) you may encounter weirdness when debugging.