My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.
Related
I recently started taking an interest in using a branching model similar to Vincent Driessens Git branching model. We have multiple developers working on the same project so using different branches for different features is a big plus for us. The model states that after a feature is developed, it is merged back into the Development branch, and on a certain time a release branch will be created from it.
Now my problem is that I don't know who added what to the dev branch since the last release, but I do want to present a list of changes that will be implemented for the next one. So the question is, how do I know what features have been added to the dev branch?
We're using TFS for version control. As far as I know I have the following options:
Better labeling and commenting of versions (currently there is no labeling and little commenting)
Linking TFS tasks to versions (not sure how to create a nice list of that yet though)
Maybe I should just follow my own options above but I was curious about how you guys deal with this.
First I would suggest you take a look at the TFS Branching and Merging Guide as it will likely answer most of your questions.
how do I know what features have been added to the dev branch?
I think the "develop" branch in Driessen's model is most closely equated to the "main" branch in the TFS guidance. I would suggest that you shouldn't merge changes into main unless they are already planned to go into the next release. Then when you are ready to release you simply branch from the latest version of main.
Keeping track of what features are intended for the next release is something that would be handled by the work item tracking system.
Separately, you may find the Track Work Item feature of Team Explorer to be helpful.
We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).
My co-workers and I are having an argument over the value and usage of Tags in release/SCM systems. We're looking to the StackOverflow community to put in their thoughts to help us resolve the issue.
One side claims that Tags are a valuable addition to release management. An example of their use: we do a Maven release, which makes a new Tag (call it 1.0) which is code snapshot used for this release. This Tag should be a READONLY branch. When a bug needs to be fixed we can make a copy of the Tag into a new Branch (call it 1.1). Bug fixes go there. These fixes may be merged back into Trunk so that the main dev branch gets the bug fixes. Finally, 1.1 is released and a Tag 1.1 is automatically created. This cycle continues. The main benefit here of the Tag is that if you ever need to re-release version 1.0 for any reason, you can just release the Tag 1.0 with the confidence that it's never been altered by anyone. Also, saying "Release Tag 1.0" is cleaner than saying "Release revision 1 of branch 1.0 which is the original 1.0 without the fixes".
The other side claims that Tags aren't providing any valuable benefit, especially in a system like Subversion with global revisions, which act like a Tag in CVS. Plus, Subversion only gives a warning when committing to a Tag; it doesn't actually stop it. Their method is developing in Trunk and upon release you'd make a Branch called 1.0. You'd continue bug fixes in Trunk and if you needed to re-release those bug fixes to production, you'd merge them into 1.0 Branch and re-release 1.0. At some point, perhaps after major fixes or features in Trunk, you'd release and make Branch 1.1. Cycle continues. If you ever need to release the original 1.0 version, you'd have to check out Branch 1.0 revision 1.
Clearly both methods work. I'd like to hear the community's thoughts on which method is preferred and why.
Edit: I'm a little worried that the "best" way depends on the underlying SCM system. Either settle on Subversion for answers or if possible keep it SCM agnostic.
From an SCM agnostic point of view, a tag is very different from a revision.
Both may be implemented in the same way, both represents a "time line", but their goal is different:
a tag represent an immutable state where all files are referenced by a unique id. It is a name representing many things but mainly a stable state, ...)
a revision represent a commit transaction (not all SCM have those, especially the old ones with a 'file-by-file approach'). All commits do not represent a "stable" state (as in "compile" or "execute" successfully). They are just a new element of the global history.
The problem with SVN is that revision, tag and branches are all implemented the same.
But I would still prefer the option where a tag is used as a "read-only" branch.
In my opinion tags are useful. There will be times at some point in the life of the project that you come across a bug or a change and you want to know if it was there in a previous release. There will be reasons to compare code from one release to another to measure efficiencies both in performance and actually the development of the code.
Sure, there is a chance you can screw it up, but it can always be undone. There really is no reason not to, and there are several reasons why it might be useful in the future. To me its a no-brainer.
I agree that you should also be using branches and doing your development there, but anytime you actually release something, make a tag out of it.
Yes, you want to use tags.
Think of a tag as just a label or a name for a particular revision. It is very helpful in my experience to tag important milestones in a project, whether it's for production release or even for interim QA releases. You often will want to go back in time and see the source code for a particular release.
If you branch upon release, you can always figure out which revision was released to production, but this is kind of a pain compared to just looking at a tag. If you don't use release branches then it will be easy to lose track of which revision was used to create a particular build.
The problem with svn is that it blurs the distinction between tags and branches. Anyone can always commit to a tag, so it's not guaranteed to be fixed/immutable. In other VCS like PVCS, a "tag" is unchangeable. You can adopt a team convention to prevent commits to tags, or even maybe use commit hooks to prevent commits to tags.
We use tags (labels) when creating new baselines. We do it once a week, but some teams do it even several times a day.
The point (for us) is always making sure the new baseline is stable: so it's not just a build, is a build that passes the entire testsuite, several hours of automated tests plus potentially manual exploratory ones too.
Then the baseline is used as starting point for all tasks during the next iteration: every new task is a new branch starting from the baseline, which is known to be stable so whatever is broken in the task should be easy to trace inside the task itself.
Normally we only put tags (labels) on the main branch (or trunk or master depending on your SCM flavour) which is the integration point for all the other branches.
When we release an official product we create a "release branch for it" so it will only receive fixes while new development stays on "main". Then these "maintenance branches" (hopefully only one or two at a time) can be tagged too.
I like to think about tags as "just a fancy name for a revision". I've always thought about them that way, and IIRC in mercurial they are just that. In subversion however, as you say, they indeed are (cheap) copies of trunk/* to tags/fancy-name/
Honestly, I'd combine the two strategies for optimal results: tag and branch upon release. Your tag is called 1.0.0, branch 1.0-MAINT. Bugfixes go into branches, and bugfix releases are tags again (1.0.1 may by a tag intended to alias 1.0-MAINT at a certain point.)
Do not forget however that tags and branches in subversion are actually the same thing: cheap copies. The only difference between them is the semantics you/your team attributes to them, so it pretty much boils down to getting people to agree on one particualr method and stick to that (might be enforced on the server, eg disallowing commits in tags/ except for release coordinators etc.)
The problem I see though with the second approach is: how are you going to make an easy distinction between software in the field if you re-release 1.0? That means that you may have a 1.0 and another 1.0 actually referring to a different code base... .
Immutable snapshots of a project's source code (and executable) are invaluable for doing testing of any kind, whether structured testing or field usage. For structured testing, you're going to be creating data that might be referenced months or years in the future. Anytime you revisit that data, Murphy's law says you'll need to know what code it comes from and unless you went to the trouble of citing a particular snapshot of the source code, it will be impossible to tell with confidence what source code corresponded to that test data.
I can't tell you how many times someone's come to me and said "This microcontroller code's not working, can you help?" and I ask them, "What version are you using?" and they say "I'm not sure" because they're not doing good release management (at the very least putting a sticker on the device, better to put versioning info in EEPROM that can be queried in realtime). >:(
In SVN, the technical difference between using a tag and tracking a revision is nil. I find myself minimizing tag use based on how SVN's implementation is simply a cheap copy and clutters up your "structure space".
The real difference comes when communicating a particular baseline to a large team of developers. Revision tracking brings an extra layer of abstraction that can become a source of errors. And as we're all aware, when you're dealing with 50+ developers, any source of error will become an area of confusion and wasted time. A verbose tag can eliminate that confusion and remove any doubt as to what a baseline's purpose is.
I'd combine both approaches. Whenever you make a release, tag it. Tags should never change, so the presence of a "1.0.0" tag is an indicator that you shouldn't be trying to release anything else as 1.0.0.
At the same time, when it came time to do 1.0.0, I'd put it onto a 1.0 branch. So the flow is: branch trunk to 1.0, tag this new 1.0 as 1.0.0, and deploy. Then bug fixes can be done on the 1.0 branch (to avoid getting mixed up with any 1.1-targetted development that may already be on trunk now) and merged into trunk. Each release of the fixed 1.0 is tagged as 1.0.x from the 1.0 branch. This is basically the approach we use at work with Perforce, and that's very similar indeed to Subversion. (Reading through the replies, I think it's virtually identical to Vincent's recommendation)
As far as the comment about tags being redundant because you have revision numbers--- that's largely true, except that tags also specify a scope: i.e. which files in the repository are covered by the tag. You can reasonably ask someone to look at /svn/proj1/tag/1.0.0 and they are immediately looking at a coherent workspace. If you ask them to look at revision X, they have to first look at revision X to see that it was changing (say) /svn/proj1/trunk/Makefile and hence deduce that /svn/proj1/trunk/#X is what they should be looking at. What happens if revision X touched files in proj1 and proj2? Which is of course evil, but strictly speaking you should be saying /svn/proj1/trunk/#X. And where is the list of revision numbers stored? How do we know that 1.0.0 is revision X? It should IMHO be possible to determine that just from the repository.
In systems like Git, tags and branches are still basically the same thing (just references to the object database), but the convention is that tag refs don't change, and branch refs do (and preferably with a specific constraint on how they change). Perforce also has "labels" which are ways of grouping a set of file revisions together independently of a changelist; which is essentially a tag, but more confusing: historically we've used changelist numbers (equivalent to Subversion revision numbers) qualified with the name of the branch they should be on to identify versions. The two are almost identical any way, so here I guess TMTOWTDI.
Using TFS, when would you label your code and when would you branch?
Is there a concept of mainline/trunk in TFS?
A label in TFS is a way of tagging a collection of files. The label contains a bunch of files and the version of the file. It is a very low cost way of marking which versions of files make up a build etc.
A branch can be thought of as a copy of the files (of a certain version) in a different directory in TFS (with TFS knowing that this is a branch and will remember what files and versions it was a branch of).
As Eric Sink says, a branch is like a puppy. It takes some care and feeding.
Personally, I label often but branch rarely. I create a label for every build, but only branch when I know that I need to work on a historical version or that I need to work in isolation from the main line of code. You can create a branch from any point in time (and also a label) so that works well and means that we don't have branches lying around that are not being used.
Hope that helps,
Martin.
In any VCS, one usually tags when you want a snapshot of the code, to be kept as reference for the future. You branch when you want to develop a new feature, without disturbing the current code.
Andrew claims that labeling is lazier than branching; it's actually more efficient in most cases, not lazy. Labeling can allow users to grab a project at any point in time, keep a history of files changed for a version or build, and branch off of/work with the code at any point and later merge back into the main branch. Instead of what Andrew said, you're advised to only branch when more than one set of binaries is desired- when QC and Dev development are going on simultaneously or when you need to apply a hotfix to an old version, for example.
I always see labels as the lazy man's branch. If you are going to do something so significant that it requires a full-source label then it is probably best to denote this with a branch so that all tasks associated with that effort are in an organized place with only the effected code.
Branching is very powerful however and something worth learning about. TFS is not the best source control but it is not the worst either. TFS does support the concept of a trunk from which all branches sprout as well.
I would recommend this as a good place to read up on best practices - at least as far as TFS is concerned.
I've tried using source control for a couple projects but still don't really understand it. For these projects, we've used TortoiseSVN and have only had one line of revisions. (No trunk, branch, or any of that.) If there is a recommended way to set up source control systems, what are they? What are the reasons and benifits for setting it up that way? What is the underlying differences between the workings of a centralized and distributed source control system?
Think of source control as a giant "Undo" button for your source code. Every time you check in, you're adding a point to which you can roll back. Even if you don't use branching/merging, this feature alone can be very valuable.
Additionally, by having one 'authoritative' version of the source control, it becomes much easier to back up.
Centralized vs. distributed... the difference is really that in distributed, there isn't necessarily one 'authoritative' version of the source control, although in practice people usually still do have the master tree.
The big advantage to distributed source control is two-fold:
When you use distributed source control, you have the whole source tree on your local machine. You can commit, create branches, and work pretty much as though you were all alone, and then when you're ready to push up your changes, you can promote them from your machine to the master copy. If you're working "offline" a lot, this can be a huge benefit.
You don't have to ask anybody's permission to become a distributor of the source control. If person A is running the project, but person B and C want to make changes, and share those changes with each other, it becomes much easier with distributed source control.
I recommend checking out the following from Eric Sink:
http://www.ericsink.com/scm/source_control.html
Having some sort of revision control system in place is probably the most important tool a programmer has for reviewing code changes and understanding who did what to whom. Even for single person projects, it is invaluable to be able to diff current code against previous known working version to understand what might have gone wrong due to a change.
Here are two articles that are very helpful for understanding the basics. Beyond being informative, Sink's company sells a great source control product called Vault that is free for single users (I am not affiliated in any way with that company).
http://www.ericsink.com/scm/source_control.html
http://betterexplained.com/articles/a-visual-guide-to-version-control/
Vault info at www.vault.com.
Even if you don't branch, you may find it useful to use tags to mark releases.
Imagine that you rolled out a new version of your software yesterday and have started making major changes for the next version. A user calls you to report a serious bug in yesterday's release. You can't just fix it and copy over the changes from your development trunk because the changes you've just made the whole thing unstable.
If you had tagged the release, you could check out a working copy of it and use it to fix the bug.
Then, you might choose to create a branch at the tag and check the bug fix into it. That way, you can fix more bugs on that release while you continue to upgrade the trunk. You can also merge those fixes into the trunk so that they'll be present in the next release.
The common standard for setting up Subversion is to have three folders under the root of your repository: trunk, branches and tags. The trunk folder holds your current "main" line of development. For many shops and situations, this is all they ever use... just a single working repository of code.
The tags folder takes it one step further and allows you to "checkpoint" your code at certain points in time. For example, when you release a new build or sometimes even when you simply make a new build, you "tag" a copy into this folder. This just allows you to know exactly what your code looked like at that point in time.
The branches folder holds different kinds of branches that you might need in special situations. Sometimes a branch is a place to work on experimental feature or features that might take a long time to get stable (therefore you don't want to introduce them into your main line just yet). Other times, a branch might represent the "production" copy of your code which can be edited and deployed independently from your main line of code which contains changes intended for a future release.
Anyway, this is just one aspect of how to set up your system, but I think giving some thought to this structure is important.