SourceSafe build using branches
I’m a novice to branching in SourceSafe, but I really need to start using it well. I think I get the concept of creating branches, but how do I “get” the right source code at build time?
For example, suppose we use the main trunk for our current releasable code. We might be simultaneously working on multiple additional functions. So we could create a branch for each of these unrelated development activites. At any given moment, we may want to make a build that has:
What if the branches are not yet ready to be merged into the trunk? Some development branches may, in fact, get abandoned.
How do I easily make a build that has the latest changes in branched code?
Then, the follow up question. Time goes by, and more changes are made to various code files. Now I want to “rebuild” a version that had some branches included in it. There are two kinds of rebuilds:
How do I maintain the ability to recreate old builds, or to easily rebuild specialized versions with more recent code changes?
I’m trying to use Visual SourceSafe 2005, but I’m open to the idea of going to a completely different tool, if it’s easier to use. Is Team Foundation Server significantly different in terms of source code management and configuration control?
Also, I wouldn't mind suggestions for books, on-line info, tutorials, classes, etc., for finding more information about how to perform smart configuration management and source control.
For example, suppose we use the main trunk for our current releasable code. We might be simultaneously working on multiple additional functions. So we could create a branch for each of these unrelated development activites. At any given moment, we may want to make a build that has:
Code from the trunk, or
Code from the trunk plus any changes made in some and/or all of the branches
What if the branches are not yet ready to be merged into the trunk? Some development branches may, in fact, get abandoned.
How do I easily make a build that has the latest changes in branched code?
Then, the follow up question. Time goes by, and more changes are made to various code files. Now I want to “rebuild” a version that had some branches included in it. There are two kinds of rebuilds:
Exact duplicate. I want to build using the same file versions as before. Or,
Same functionality. I want to build using the latest versions of the same branches I had included before.
How do I maintain the ability to recreate old builds, or to easily rebuild specialized versions with more recent code changes?
I’m trying to use Visual SourceSafe 2005, but I’m open to the idea of going to a completely different tool, if it’s easier to use. Is Team Foundation Server significantly different in terms of source code management and configuration control?
Also, I wouldn't mind suggestions for books, on-line info, tutorials, classes, etc., for finding more information about how to perform smart configuration management and source control.
ASKER
Let’s see if I understand what’s written in that document. Although SourceSafe has a simple-to-use Get Latest function, essentially it doesn’t have the ability to “get a labelled version”, or “get all files from a specified date”. But Team Foundation Server does, using the Get Specific Version command. Is that about right?
Depending on how easy that command really is, that sounds like what I’m looking for.
Depending on how easy that command really is, that sounds like what I’m looking for.
The command is integrated into Visual studio from the right click menu of an item to GET specific version, also from command line the command TF GET can be issued using the TFS Command line utility TF.exe
http://msdn.microsoft.com/en-us/library/z51z7zy0(VS.80).aspx
However the main difference is that VSS is just a source control system , while TFS is much more than that., Smart source control is just a feature of what it has to offer.
Before you decide to move to TFS you will have to consider if it is suitable for your team,,or smaller teams who were comfortable using VSS , TFS 2010 Basic is the best upgrade path IMO.
More info below
http://blogs.msdn.com/b/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx
http://manicprogrammer.com/cs/files/folders/st_jean/entry10274.aspx
http://msdn.microsoft.com/en-us/library/z51z7zy0(VS.80).aspx
However the main difference is that VSS is just a source control system , while TFS is much more than that., Smart source control is just a feature of what it has to offer.
Before you decide to move to TFS you will have to consider if it is suitable for your team,,or smaller teams who were comfortable using VSS , TFS 2010 Basic is the best upgrade path IMO.
More info below
http://blogs.msdn.com/b/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx
http://manicprogrammer.com/cs/files/folders/st_jean/entry10274.aspx
ASKER
That's an awful lot of information, I think my original question got lost. I'm looking for a "how to" description of what I believe is a fairly common code management scenario. Can you recommend a source that clearly explains to the novice configuration manager how to use a tool (any tool) to get this done?
Clearly, TFS is a powerful tool. I can spend days/weeks reading up on it, but I bet I won't really know how to use it until I buy it and install it...which I don't want to do if I can't first figure out how to do what I want. I know TFS is a lot of things, but all I need to know about now is source code version control .
Clearly, TFS is a powerful tool. I can spend days/weeks reading up on it, but I bet I won't really know how to use it until I buy it and install it...which I don't want to do if I can't first figure out how to do what I want. I know TFS is a lot of things, but all I need to know about now is source code version control .
You can still do it with VSS if you need to , using SS Get & MSBuild from command line in conjunction with Labels
- On the build machine :-
SS GET -R -Vllabel_name or SS GET -R Project_Folder
then MSbuild your_project_or_solution_f
you can follow that by running any custom deployment scripts you may have .
With TFS builds things are much easier, all this and much more is configurable from Visual studio with Team explorer installed.
The possibility to create Custom Workflows in TFS build 2010 is also amazing, you can also run tests, send notifications, assign work items( for those who break the build maybe), Deploy to custom paths, or as part of Continuous integration build ,run external commands ,etc.. through a few clicks.
a few links for reference.
SS GET command reference
MSbuild command reference
Interesting Presentation about Team build 2010
What's new in Team build 2010
Hope this helps.
- On the build machine :-
SS GET -R -Vllabel_name or SS GET -R Project_Folder
then MSbuild your_project_or_solution_f
you can follow that by running any custom deployment scripts you may have .
With TFS builds things are much easier, all this and much more is configurable from Visual studio with Team explorer installed.
The possibility to create Custom Workflows in TFS build 2010 is also amazing, you can also run tests, send notifications, assign work items( for those who break the build maybe), Deploy to custom paths, or as part of Continuous integration build ,run external commands ,etc.. through a few clicks.
a few links for reference.
SS GET command reference
MSbuild command reference
Interesting Presentation about Team build 2010
What's new in Team build 2010
Hope this helps.
ASKER
As far as I'm aware, I can apply a label to a single file or to an entire project. How do I manage branches, though? Like I said, I want the ability to make builds using code from the trunk and any (changing) number of branches. If a branch (i.e., development project for a new feature) contains many files, how do I mark all those files in such a way that I can do a get/build on my application either with or without this new feature?
I think I understand how "GET" works in VSS (and, to some extent, in TFS). It's the preperation for a GET that I do not understand. How do I set up a real-life development life cycle of source code files so that I can do the right builds at the right time?
I think I understand how "GET" works in VSS (and, to some extent, in TFS). It's the preperation for a GET that I do not understand. How do I set up a real-life development life cycle of source code files so that I can do the right builds at the right time?
Since SourceSafe does not support branches (as it does not support project versions at all), there is no way. SS GET only works with file version (almost useless), check-in date or label. You cannot open a new branch, it is a straight-forward revision management.
Hence to only way to manage something like branches is to manage it OUTSIDE VSS, while the files still can be hold in VSS.
Other Source Control systems like CVS and alike allow for branches.
Hence to only way to manage something like branches is to manage it OUTSIDE VSS, while the files still can be hold in VSS.
Other Source Control systems like CVS and alike allow for branches.
ASKER
Qlemo - SourceSafe does support branching and merging. But what I can't figure out is an easy way to make builds with branches without first merging. For example, if I have a main trunk and three separate branches (say, for three separate new features in development), how can I make a build that includes the latest code from the trunk plus all the changes in branches A and C but not the changes in branch B -- without first merging A and C back into the trunk?
If this is possible in SourceSafe or in TFS, can someone show me a concrete example?
If this is possible in SourceSafe or in TFS, can someone show me a concrete example?
No, you can't. You can check out arbitrary versions (if configured), you can check out multiple times, but you can't merge anything independant from the current (file) version. That is not branching. Branching is if you can take Version 1.3.5 and build a 1.3.5.1, while there is a 1.3.6.2 and 1.3.4.3.1. That is nothing you can do with SourceSafe.
The branching support with sourcesafe is indeed minimal.
as for TFS , it fully supports branching and merging to its full extent, for example I have 3 team builds , one for the DEV code brach, one for QA branch , and the other for production branch, we do create new team builds for temporary release branches, basically all you need to do to create a team build is as below
http://msdn.microsoft.com/en-us/library/ms181286(VS.80).aspx
as for TFS , it fully supports branching and merging to its full extent, for example I have 3 team builds , one for the DEV code brach, one for QA branch , and the other for production branch, we do create new team builds for temporary release branches, basically all you need to do to create a team build is as below
http://msdn.microsoft.com/en-us/library/ms181286(VS.80).aspx
And to answer this specific question
"how can I make a build that includes the latest code from the trunk plus all the changes in branches A and C but not the changes in branch B -- without first merging A and C back into the trunk?"
No, you can't, not without merging into an intermediate release branch, not with Sourcesafe, TFS or any other build software , Build programs will need a particular solution to build, if you did not merge the code you wish to include into the build into the solution to be built, it is not going to be included in the build.
Merging itself is not so bad, Conflicts are bound to occur from time, you can resolve them using any decent Text comparison tool (windiff,winmerge,etc..) other than the merge tool in Visual studio if you don't like it, in time you will discover that resolving code conflicts during merges is going to be an important part of your SCM tasks.
"how can I make a build that includes the latest code from the trunk plus all the changes in branches A and C but not the changes in branch B -- without first merging A and C back into the trunk?"
No, you can't, not without merging into an intermediate release branch, not with Sourcesafe, TFS or any other build software , Build programs will need a particular solution to build, if you did not merge the code you wish to include into the build into the solution to be built, it is not going to be included in the build.
Merging itself is not so bad, Conflicts are bound to occur from time, you can resolve them using any decent Text comparison tool (windiff,winmerge,etc..) other than the merge tool in Visual studio if you don't like it, in time you will discover that resolving code conflicts during merges is going to be an important part of your SCM tasks.
ASKER
Well, if it can't be done, that explains why I haven't been able to find a way to do it. But then how is this done? Maybe I'm asking the question the wrong way. How do we maintain multiple simultaneous development efforts without committing to any of them?
Typically we would have a main development "trunk", which represents the baseline, as-released code. This code would contain all bug fixes to the existing version of our product. We also develop new features, but can never tell in advance which new features would be ready for release in which order. It would seem to make sense to make a branch for each new feature. On any given day, we might want to make a build that includes the baseline code plus any number of features...but the next day might need a build with different features. The branches would be kept separate from the trunk until such time as its development is approved for release, then we would merge that branch back into the main trunk. But until that final approval, it always has to be possible to make a build without any (or all) branches. If I make an intermediate merge/build, the changes from the selected branches will have been placed into the trunk code. How do I separate out the changes from that branch so that I can make a new build without those changes?
Maybe I've got the wrong concept; maybe branching is not the solution to this problem?
Typically we would have a main development "trunk", which represents the baseline, as-released code. This code would contain all bug fixes to the existing version of our product. We also develop new features, but can never tell in advance which new features would be ready for release in which order. It would seem to make sense to make a branch for each new feature. On any given day, we might want to make a build that includes the baseline code plus any number of features...but the next day might need a build with different features. The branches would be kept separate from the trunk until such time as its development is approved for release, then we would merge that branch back into the main trunk. But until that final approval, it always has to be possible to make a build without any (or all) branches. If I make an intermediate merge/build, the changes from the selected branches will have been placed into the trunk code. How do I separate out the changes from that branch so that I can make a new build without those changes?
Maybe I've got the wrong concept; maybe branching is not the solution to this problem?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
With SourceSafe we have a similar approach. Important projects have a PROD and a DEV "branch" (different project paths). Of course both are evolving linear, but you can decide at any time which features or changes should be taken over from DEV to PROD, by merging. Urgent bug fixes can be implemented on the PROD code directly.
ASKER
That codeplex link is great. Clear, simple, yet useful explanations of some basic code configuration scenarios (despite all the typos).
It looks like my best solution is to create a separate branch for each development project (for us, there will usually only be one or two at a time). If needed, we could also make a separate "merged" branch for each combination of dev tasks that we want builds for.
SourceSafe is unstable and approaching end-of-life, so we're gonna drop it. The next question is to decide whether to go to TFS 2010 Basic or use one of the many smaller (cheaper) code configuration tools. But that's a decision for another day.
It looks like my best solution is to create a separate branch for each development project (for us, there will usually only be one or two at a time). If needed, we could also make a separate "merged" branch for each combination of dev tasks that we want builds for.
SourceSafe is unstable and approaching end-of-life, so we're gonna drop it. The next question is to decide whether to go to TFS 2010 Basic or use one of the many smaller (cheaper) code configuration tools. But that's a decision for another day.
instead of messing around with extremely complex msbuild tasks that will get more complex as your requirements evolve, Team build makes building software a walk in the park.
TFS is way too much stable than VSS and offers much more better functionality than VSS , including work items , Bug tracking Project management features, reporting interface , integration with unit tests ,etc..
check this document for some nice info
http://manicprogrammer.com/cs/files/folders/st_jean/entry8575.aspx