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 :)
Related
Just installed the latest Umbraco (7.2.1) package via NuGet. My development environment is as follows:
Umbraco is installed installed on IIS8 as shown below and is all up and running.
My Visual studio project is set up as shown below (For the sake of clarity, any folder/file excluded from project is not in included in my source control.
The content folder houses all scripts, images & css
On build - bin, config, content, masterpages, usercontrols, Views, xslt, default.aspx, Global.asax & the transformed Web.config are copied to the IIS instance (I don't like running Umbraco in the same place as my project, it just seems messy.)
Is this an appropriate way of developing for Umbraco? Am I missing anything, my biggest concern is whether or not I should include the umbraco & umbraco_client folders in version control and in the post build action. Any suggestions would be great.
There is some debate over what should and shouldn't be in your repository and ultimately it comes down to personal preference. I used to only add custom files and files that I changed from the Umbraco install such as the config files however since the introduction of the Nuget package I do put all but the binaries into source control because when I upgrade via Nuget later on I can easily see changes and merge customisations back in.
It saves a lot of hassle running Umbraco directly (IMO) especially if you make any changes via the UI and if you're not running it directly then there is little point really in using the Nuget package because you will end up with a bunch of unused files in your project. In your situation you might as well keep your project clean and do a manual install into the location IIS is using for the site and only keep files in your project that you have created.
This is only my opinion so take from it what you wish but hopefully it is of some help.
Simon
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.
At my work we are just starting to use TFS with our team of 4 developers, and are at the same time transitioning from single developer projects to team projects. We are mostly using the default settings in TFS
I was the first to push up a simple Silverlight MVVM project consisting of a solution with a Silverlight and a web project.
When my team-mate pulled down my code and tried to compile, he was faced with many missing references (.dlls), Expression blend SDK, Ria Services toolkit, Telerik controls, simple mvvm toolkit, silverlight toolkit, etc.
What do we need to do, to add projects to TFS that have everything needed to be compile it when the next developer pulls it down?
There isn't a really good way to do this all automatically. What you'd generally do this this:
in your branch create a bin folder next to your src folder.
in the bin folder create folders for each component you're relying on
in each folder place the setup or a link to the setup
in each folder place the binary files you're using in your solution
in each folder place a readme with any manual steps that must be completed
if wanted you can create a powershell script or batch file which installs all required components. It isn't too hard to detect whether or not an application is already installed using powershell and wmi
Now you'll have to fix a few things in your solution:
make sure your references don't point to the GAC, but that they point to the assemblies inside the bin folder of your branch
make sure all the paths are relative to the solution. Any c:... paths will not carry over from one system to another
I found that the easiest way to do this is to unload the project in Visual Studio and then edit it. You can then quickly add hintpath="..\..\..\bin\component attributes to each reference. There are a few blog on this subject which provide different solutions which all solve this same issue.
This setup allows you to at least get the latest version of any solution and build it without having to install any tools. If some of your components rely on visual studio add-ins, then the designers for these tools usually won't work, but at least you're able to build them.
An often used alternative is to create a Virtual Machine base image for your project and install all the required components onto it. Then copy the image to each developers workstation and sysprep it to ensure they all have a unique name and identifiers. When the project needs to update its dependencies, let one developer create a new clean machine and re-distribute that to all team members.
If you're using Windows Server Virtualization or VMWare, it's quite easy to create differencing disks and allow developers to access these images remotely.
Another approach would be to use NuGet and script NuGet using a powershell script for your solution. This will work for most cases, but products like Expression Blend still need to be installed separately.
We are moving to TFS 2010 (from PVCS) for source control and work item tracking
As I understand it you should have under source control for each TFS project everything that projects solutions, etc. need to build.
This OK for new .NET solutions/projects, but we have a large collection of legacy Delphi 6 projects with shared source libraries we want to port into TFS for source control and build. It is how we manage multiple TFS projects that want to sare a specific set of source files between them that is my problem here.
Historically with PVCS we have had projects for each solution (say A & B), and a seperate project for common source code (say C). Users would get C then get either A or B (checking out as required) on disk this would maifest as something like this:
$\Projects\C
$\Projects\B
But B & C are seperate PVCS archives.
Now fast forward to life with TFS 2010 as our ALM solution...
If we create a TFS project (1) that contains the source repository for the common code (C), that projecs can obviously access it (lets say the TFS project also contains the solution A) and all is good.
We now create a new TFS project (2) in which to make solution B. Beacuse solution B is wildy different to solution A we had no reason to share TFS project 1's source control so we made a new source repository rather than branching from 1. Now later on we discover a need for solution B to access some common files from C (in 1). Oops!
The question is this; can I perform some source control wizzardry that lets me add a folder in the 2's soruce control that is a (to steal a file system term) symbolic link into 1's source control for the common code C?
Edit
I should point out this is all legacy code and the shared source library (C) is just that shared source it does not build into a library or other binary we could simply add to A or B.
In TFS 2010, as you may know, they introduced the concept of a project collection (PC). Each project collection is an aggregate for team projects (TP). Each PC is stored in a separate database, and the VCS is stored in the database.
This means that there is one VCS repository per PC, not TP. Each TP is (by default) the root folder in each VCS (i.e. TP1 will be at $/Prj1, TP2 might be at 4/Prj2, etc.)
One more point is that you do not want to have one solution per TP. Think of a TP as a suite of products, and a solution as a part of that.
Symbolic links, as per Visual Source Safe, no longer exist in TFS, and I'm not sure you need them. It is not considered a good practice to create a dependency between one solution and the source code of another solution.
What I suggest you do, is have each solution in your codebase depend only on its own code, and on other solutions' binary deliveries.
What will happen is that if Sln_A depends on Common_Sln, you will build Common_Sln, and bring its binaries from the drop location as part of your Get. Then, add the binaries as references.
This will solve your problem, with the added benefit of transforming a tight coupling where a dependency may break your dependent solution's build, into a situation where you do not change or upgrade your dependencies until they are ready and you are ready for them.
Does this help solve your problem? This is how I do this with the projects I consult on.
HTH,
Assaf.
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.