This project has moved and is read-only. For the latest updates, please go here.

Identify an artifact or Multiple Artifacts for a Project

Jun 4, 2013 at 3:04 PM
Hi all,

In TFS I understanding there is the branching and the labeling but it also seems with TFS that it's too much information or risky, respectively.

Assuming we have a multiple applications comprised in 1 team foundation collection (TKC) and they total comprise 2000 artifacts:

If we have a project that let's say only changes 6 of those 2000 artifacts and 2 developers working them:
  • Creating a branch works BUT it branches off the main and thereby makes a copy of the 2000 artifacts so the 6 can be changed and isolated. That would utilize a lof of unnecessary space for changing just 6 artifacts BUT it would work.
  • Creating a label works BUT labels are free-form text and meaning each developer could label it with a different name.
A code-promotion type branching model sounds reasonable off the Main to QA and release for stabilization but what is the best method to isolate and identify the changes to those 6 artifacts in this example?

If there was a way to promote and identify without a label (due to the risk) that is ideal but I am not seeing it with TFS nor did I with VSS.

Any assistance and inforamtion on this would be greatly appreciated.
Jun 5, 2013 at 1:44 AM
First, it's important to understand the facts about TFS branching and disk storage. If you have a trunk (MAIN) with 2,000 artifacts, and you branch it all, very little extra space is used on the server. However, when a developer gets latest on that branch, they will have a local copy. So their local disk space gets used. But that is not normally a problem. It is only if you change some of the files that space is made for the changed copy. The algorithm used varies depending on the change.

If the 2,000 artifacts represent several different applications, and they are independent, then you might make each of them a trunk and branch off of them. That reduces local disk use since you only need to download the project you are working on.

I would encourage you to skim the entire branching guide that is available in the downloads section of this project. It has some great information that will help you see alternatives. When you see something of interest, you can slow down and study it carefully.

Jun 17, 2013 at 10:07 PM
Hi Davidkallen,

So sorry about the delay.

Yes, I believe it's not taking much space on the server as I believe that is just the meta stored on there. However, you are correct and that's what I'm getting at. If a developer is getting out the latest on a branch they are getting everything and probably 99.9% of that they will not even use. If they are working simultaneously on 2 branched projects and they need to keep the branches isolated they would then need to get the latest on the other project as well which means they would get all that yet again and 99.9% of those they would not use either. So, yes, you are correct in that it's not taking much space on the server but rather on the local copy.

I see what you're saying on if the applications are independent and all making each of them a trunk (or main). That would be 1 TKC per application would it not or all in the same collection just a different heirachy structure per application? However, the release would entail everything for each of those trunk's.

I am looking through several different documentation sets and PDF's. All great information but little to point a finger at and say I really need to look at this and take a deep-dive into.

That's sort of why I am posting the question.

Jun 18, 2013 at 1:00 AM
How much disk space is consumed by the entire collection of 2,000 artifacts? It should be easy to obtain by looking at your development machine.
Jun 18, 2013 at 2:04 AM
We are currently using SVN. But yep, familiar with how to get the size on the development machine or local machine.

The 2,000 artifacts was just an example and very close to the disk size but here are the numbers:
  • Size: 2 GB
  • Artifacts: 17,890
  • Folders: 1,400
Now, that is for 1 project. For instance, I am currently involved in 3 and each on it's own branch off the main/trunk. So that's about 6 GB in disk space. 53,670 artifacts, 4,200 folders.

It took a good 15 minutes to download locally for each one of those branches. As may know, SVN downlaods the file and meta for the .svn to track each artifact. Much like TFS would with it's local workspaces. (TFS 2012 with the predominant local workspace.)

The really sad thing, is on 1 project I had a total of 10 artifact changed, the 2nd - about 22, the 3rd - 2.

I want to come up with a plan to not require a download of all that yet keep the identification of each project and artifacts comprising the project for isolation merges. So, that if let's say the release upcoming was initially scheduled for the 3 projects turned out in the midst of system testing that only 2 of those 3 were going to go in; I need to be able to remove the 1 of those identified to NOT go in and remove all the elements. Yielding the system and only those 2, rebuilding and having those in just system test.

I thought about the use of version labels. That would avoid the need of branches and all BUT labels in TFS and in VSS are risky as the reason: they are free-form text on the name which means one developer could label something "Test" and the other developer labeling it "test" (really meaning "Test"). I have used things like PVCS which had the promotion group that was staticly named which enforced consistency and they had the version label as well that was not static. However it was somewhat slow, a little outdated and did not integrate well with VS as TFS does, and work with a fully integrated bug tracking and build aspect as well and the other features of TFS.

I have figured a way to remove about 2,000 of the 17,900 which comprise common elements like the DAL and Placeholder logic as well as other "common" items. I would put them in a separate tree structure on the same TKC and using the builds for a reference. As well, the projects downloaded would use a reference to the static locations as well. That would require the "common" to be downloaded onces into the workspace and each project having a reference to that workspace. However, that still leaves about 15,900. By the way, not of those artifacts in the 3 projects are touching the common anyway.

I'm sorry about all the detail. Just wanted to do my best to explain what I'm dealing with and what I'm trying to avoid in the use with TFS. Again, I haven't really found any good information on any of the materials and documents that outlines a good way of dealing with something like this.

Any information, ideas, suggestions you have would be greatly appreciated.

Jun 18, 2013 at 2:47 AM
How often do you create a branch?

As a reference for performance, it takes me only 7 minutes to download a complete new branch with 2 GB and 27,000 files. And my source code is on the internet in the Microsoft TFS cloud service. So if you are getting 15 minutes, you may have network or server issues.

But regardless, I admit that is an annoying delay. But you only have to do that once, when a branch is created.. Later, during development, when you get latest version, it should be much quicker for just changes.

At work, we only branch once a month. So waiting 10 minutes once a month for a developer is not a problem. You just go get a drink of water, or go to a meeting. And you are done when you return. How often do you branch? That is the key to how big an issue this is in real life.

Jun 18, 2013 at 4:20 AM
Whenever we create a new project we have it on a branch. So, how often really is based on how many projects we have going on that is scheduled for a release. You could associate it to a feature branch as that is essentially what they are. Then the SYSTEST will be overwritten by merges to it and then a release branch is created per release.

I could have sworn is takes me about 15 minutes then again, I am doing other things at the same time too which I'm sure that could slow things down as well. I have a an adequate pipe of about 40 MB/SEC taking into account VPN, obviously faster without. That's just me though and we have others who are geographically separated.

I could only imagine it would be quicker on the changes as your just dealing with the local workspace or changes that are identified with that; just like with SVN. The merges would be the same.

I just keep thinking there has to be a better way and not have to deal with the 15 minutes or what have you. I mean it only makes sense. If I have 17,890 files or you have 27,000 files each one is not being touched and only some are. Why not just get them once and create a branch based on just the needed artifacts (with the option to add or remove)? That option or possibility does not exist does it? I have never seen in documentation that mentioned it.
Jun 18, 2013 at 4:47 AM
no. I've not seen anything about creating a branch on just specific artifacts.

But here is an idea. I just tried it. Make a full branch of all 17,890 files. It only takes a few seconds, right? Because it just makes pointers on the server. Then if you know you want to just change 3 files, get latest on just the files you want, at the time you want them. Just in time editing. Then change them. Of course, that makes no sense if they are normal .Net projects because you want the solution and project files and all supporting files or you cannot build. But if you want to build the solution then you want the whole thing so I don't see the point in what you are trying to do in the first place. BUt if you really just want to touch 3 files out of thousands, you can get just those files. Nobody says you must get latest on all of them.

As a radical idea, I know TFS and Visual Studio support GIT now. It is a totally different paradigm. If you and your team are willing to learn a totally new approach to version control, it might be a better. But I cannot say as I have zero experience using it.

Jun 18, 2013 at 5:26 AM
If you are using .NET you must get all of them because like you said, the solution and the project files for a build.

However, actually they are .NET files and makes perfect sense if you get the common items 1 time and 1 time for all the projects, maybe per release, and put it in your workspace. This is essentially the baseline version or the version of the last release. You obviously branch from the main and then you get the 3 files from the branch and do a get latest off of those and have the workspace of the branch be the same as the workspace for baseline.

The references of the projects in the .sln would all have to be in your workplace. You even do an MKLINK to make a symbolic link to make the referencing easlier with the .sln.

That may actually work-out, kinda thinking and typing here.

One that situation would have 1 hit on time to take the 10 minutes to get that latest from the common and 1 for all the projects. Then after that you still have the branch and if you only need to modify those 3 files. Then you have only those 3 files from the branch in your workspace.

You can still build and compile the .NET using those 3 changed versions. The other projects would use the same baseline version in the workspace but hmmm...wouldn't isolate like the Project 1, Project 2, etc because those change from each Project would go into the base the the projects really aren't isolated, per say. It would be like a unit test system test.

Let me think about this...there are pro's and con's.

I will play with this tomorrow. I will let you know the outcome.

Thanks for the dicussion davidkallan. It has me thinking.

Again, I'll let you know how that works out or if it is even within reason considering.