I'm wondering if there is a way to selectively branch files and folders in TFS. We currently branch the trunk but it is a bit cumbersome.
Lets say I have the following structure:
--trunk
--base code
--internal code that relies on base code
--client code that relies on base code
I would like to branch base and internal and base and client.
if this is not possible what would be a good folder structure to facilitate our needs?
Rather than including base (the dependency) in the source for your internal/client, a typical approach is to have base in it's own branch. Then have internal and client take a binary dependency rather than a source dependency on base.
This is realized by having a lib folder in each internal and client, that contains a copy of the specific version of base on which they have a dependency. This allows you to evolve base and the applications that depend on it independently, and it allows the internal/client developers to make an explicit decision about which version of base to depend on.
Related
situation:
we have multiple feature branches, one main branch;
one particular project has multiple XML files, key-value pairs for different languages;
only one person doing translation, not programmer, but an analyst;
we use feature branches to separate features and scope of testing; different QA is responsible for testing on different branch for different user story.
when a user story is done, we merge the feature branch up, and sync down to other sub branches
those language XML files are large, say, roughly a few hundred key-value pairs in each.
challenges:
challenges come when multiple feature branches need translation, and the translation changes are done in the same file, say Japanese;
QA occasionally files a translation bug fixed in another branch;
the analyst is confused which branch to work on;
very high chance when merging, one version overwrites another version; because when we merge from a branch, the default logic in TFS takes the newer version to overwrite it. Most of time it works fine, but in some cases it failed, which increases the complexity of merging.
of course those challenges are manageable.
But ideally, I really think those static files should belong to one place instead of feature branches, so all feature branches share the same translation pack.
I could use an internal nuget source to host the language files, but it will increase the work every time we make a small translation change.
or I could setup TFS to use relative path, but then I need to update build definition in the build server and make sure the local build can grab the correct file.
Is there any other recommendation?
Thanks
If you have any shared internal libraries then create NuGet packages should be a good way , and you can also create a vs solution just containing that library.
For XAML build, add a post build command to create the nuget package, or extend your tfs build template to do it (there's a number of templates out there that already do this).
For VNext build, there is a new VSTS Task called "NuGet Installer" this allows you to check in your NuGet.config file and specify the different package sources. Run this task before you run MSBuild. More details please refer: How to get TFS2015 Build (Build.vnext) and NuGet package restore to use custom package sources
Moreover, I think if your product or app haven't been published to user, the update changes of translation could not be so frequently. After all, just some translation and language packages. You could update it once or twice during an iteration.
This is a problem we have been living with for a while already. Suppose that I have three files:
a FxCop ruleset, containing our basic Code Analysis rules
a Resharper .DotSettings file, with company defined naming conventions, for instance
a StyleCop.Settings file, with some of the default style cop settings disabled
How do I share these kinds of company wide settings files across multiple TFS Team Projects?
At the moment, we have these replicated in a Resources folder in each project, but this is quite a maintenance nightmare, since when we decide to update a few rules on any of these files, we have to update them in a lot of different places.
One approach I've seen is to create a team project specifically to store these files on TFS, for instance $/Core, and by some means share the files this way, either using workspace mappings or branching the project into the other projects.
I don't like this primarily because it requires manual intervention and hardcoded paths. Ideally, I'd like an approach that was not intrusive, i.e. a developer gets the project from source control and compiles without any problems. No need for separate mappings into specific forlders, setting environment variables, anything like that.
At the same time, I'd like to keep the history on these files, so it would be nice if they could still be source controlled. Since they are central to the company, it would be ideal to have limited permissions on them, and that each change was documented appropriately (changesets provide that).
Another approach that crossed my mind was to share these settings via company internal nuget packages. Say for instance that I do have this $/Core project, but instead of using workspace mapping or branching it inside the other projects, I publish a nuget package (or more than one even) containing the configuration files, and add these packages to each project that needs it. I can then use relative paths to the package folder when referencing them, and it would require no manual intervention on the developers part.
Although using nuget would probably work fine, this solution seems weird to me, since nuget packages are meant to be project specific, but this would be "whole team project" specific instead. Again, using this approach, I'd probably have to add the package to one of the projects inside one of the solutions inside each team project. This is actually quite similar to how test adapters are shared now. For instance, NUnit already support this approach. I feel I'd have to do something very similar to that if I went with an internal nuget package: each solution would have to load the package at least once.
Is there some other way to share these kinds of things across the whole company, while still maintaining them on source control? What if I loosened this constraint, and accepted that they don't need to be source controlled? Would it open up other options to share them?
If you go down the NuGet route, you could create Packages for your FXCOP and Resharper files, and then store them in a local feed.
For Stylecop you could use the existing NuGet Package for StyleCop.MSBuild and then repackage it with your own settings file.
The scenario is as follows. I am working at a company that started out with one iOS application. Now, the company is interested in creating a second iOS application, that shares much of the same code base. The original application was not written with the intention of being reusable, as it was not known at the time that a second similar application would be created. In future, there may be even more similar applications that build on the existing code base.
We are trying to determine the "best" option with respect to how we maintain the source code going forward. So some of the options we're contemplating include single repository with shared library, one repository for shared library and one repository that contains all of the iOS applications, one repository for shared library and one repository per iOS application, etc etc. There's also the question of whether to use git submodules or not if using multiple repositories etcetera.
Currently, the two applications + library are all in one git repository. One of the advantages of this is that a developer can checkout a commit of the single repository and expect the product to build, without having to worry about updating multiple repositories. Basically, the developer doesn't have to be concerned with multiple repositories needing to move in lockstep with one another or requiring some specific combination of repositories commits for a build to work. The developer also doesn't have to worry about cases where another developer may have remembered to commit one repository, but not the other.
Here are some more things I've considered:
Submodules
I've used submodules before, but am no expert. My understanding is that the "super" repository containing a submodule also stores a reference to a specific commit of the submodule. This partly deals with ensuring that multiple repositories (i.e. application + library) would move in lockstep, though I'm guessing there are still issues with needing to manually pull changes from the sub module. Also, issues with a submodule commit not being available to pull if a developer happens to forget to push its changes and it is referred to by the super repository.
One nice aspect of submodules is that it creates a stronger semantic separation between the library and the applications which happen to use the library. Whether this is useful in practice, I'm not sure.
Single repository
As previously stated, this is what we're currently doing. Two applications + shared library code all in one repository. The greatest concern has been around the relatively non-existent ability to isolate changes between project one and two and the library. E.g. someone makes changes to both some library code and some application code in a single commit. Then, another developer just wants the changes in the library code.
One nice aspect of single repository is that everything moves in lockstep - nobody has to worry about keeping multiple repository versions matched. If using XCode workspaces, refactorings are even possible across the two applications.
Branching
Another option is to use some kind of branching model, either in a single or multiple repositories, to manage the code.
Ultimately, we're just trying to figure out a good model going forward for managing two or more iOS applications plus shared library code. Whether this be achieved via multiple repositories, submodules, branching models, or something else. Any general suggestions on the pros and cons of the various options?
Use submodules. You don't need to be an expert because they are really easy to use. Especially when combined with a GUI like SourceTree. I had the exact same scenario as you and that is what I did. SourceTree will even warn you if you are trying to commit a repo that has uncommited changes in a submodule.
A single repository is ludicrous. That would mean that every time someone new wanted to download a project, they would have to download them all.
Branching is going to turn out to be too complicated with making bug fixes that apply to all relevant branches.
The structure I have for my current project is:
Project repo (For the project I am personally working on)
-Project base repo (For shared code between team members)
--Utilities repo (For code that is reusable in any project)
Cocoapods, they make managing related code between applications simple.
We had a similar base for a suite of apps and initially it was a huge pain to manage but once you get custom cocoapods running you will never look back. You should check out this for a starting guide on managing your own cocoapods.
It's free, it's powerful and you will wonder why you never used them sooner.
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)
TFS 2008 and Common Libraries
I have created a Team Project called "Common Library" that will host code used in numerous different Team Projects throughout TFS. For sake of argument, lets say we have 2 distinct Librarys under the "Common Library" Team Projects, MailProject and LoggingProject. Other projects throughout TFS will be using the binary representation of these projects via branching and not the actual source code.
What is the best way to set up the folder structure for this Team Project? Do I add the project to the "Common Library" and simply "include" the bin/release folder as part of the project?
I have seen some examples of people creating a seperate "Deploy" folder. I assume this is synonamous with the bin/release folder?
We do not want the source code available in other solutions.
Currently, each project has the dll included in the project. Using a mailing module as an example, many projects need the ability to mail. The common module is very stable and mostly static.
However, what if there is a change in the mail module. It seems there would be a better way, than to check out each project and update the dll. Is it possible to allow TFS to grab the latest mail module any time a 'get latest' is called? Either explicitly or implicitly.
Unless you really require the source code for the libraries to be available in the other solutions my advice would be to include the binaries for the libraries in the projects that would use them not really having any explicit link between the two in TFS. Custom labelling of the library builds could be helpful to easily return and rebuild any chosen version of the shared libraries.
If the shared libraries require different versions for different projects then the obvious solution would to create a separate branch for every version of the libraries that need to be customised to a particular project.
TFS does not have a concept similar to SVN's 'externals' though - so if you include a branch from the shared libraries in a project and than branch that project it is very difficult to propagate changes correctly.
I suppose you could also use the Get task in the build and get the latest version of DDLs into the current project from another one, but verify if you can point of Workspace of another project (I have not tired it and MSDN is somewhat vague here). You might need to have a separate workspace for the shared project.
Yet another alternative would be to publish the DLLs for common components to a known location on every build of the shared libs and for individual builds to get whatever version is available from that common location (network share) even via the Copy task. This is simplistic and may cause problems with versioning of the common components but should work well enough in simple case.