Is it possible to use lables in this manner? I want to check with the authorities before I recommend it to my team.
I want to be able to right-click a folder and apply a label to it (ideally to all the files in the folder) when we run a build. That means that in another few days/weeks, I need to be able to apply a new label to the current versions of all files in the tree without overwriting all the older labels, even if the file hasn't changed. So does labeling create a new version? And does it recurse onto all files in a folder?
Then, I need to be able to go back to the folder, and get all of the files in the tree which share a common label. Is this even possible? (It has to be recursive, we've got too many files and folders to even attempt such a thing manually)
I know branching can be used in this manner, but I'd rather get all at a label, and break the connection to source control, rather than keep track of 2 branches. We can branch at major releases, and label at minor releases.
Can I use labels for this:
Moderator: SourceGear
Perhaps an example will help clarify how labels work:
If you label $/foo with the label "build 2000", then all the files and folders underneath $/foo will be labeled "build 2000". The next day you can label it "build 2001", and again, all files and folders will contain that label for the version that existed at the time of the label. If $/foo/test.txt was at version 10 for both labels, then version 10 will be retrieved when you later do a Get by label on $/foo for either "build 2000" or "build 2001".
What you can't do is label $/foo with "build 2000", and then later label it again with the same string "build 2000". Each label has to be unique. You would have to delete "build 2000" and then apply it again to have it apply to the current version of the tree.
Labels don't create new nodes or entries in the tree. They are simply text strings that are associated with versions of a folder or file.
If you label $/foo with the label "build 2000", then all the files and folders underneath $/foo will be labeled "build 2000". The next day you can label it "build 2001", and again, all files and folders will contain that label for the version that existed at the time of the label. If $/foo/test.txt was at version 10 for both labels, then version 10 will be retrieved when you later do a Get by label on $/foo for either "build 2000" or "build 2001".
What you can't do is label $/foo with "build 2000", and then later label it again with the same string "build 2000". Each label has to be unique. You would have to delete "build 2000" and then apply it again to have it apply to the current version of the tree.
Labels don't create new nodes or entries in the tree. They are simply text strings that are associated with versions of a folder or file.
I found the snapshots feature, and am curious if anyone has used it in the manner I was describing? Is it possible or recommended to save snapshots for QA builds? can files in a snapshot be unpinned, modified, checked in, and repinned again? (as bad a practice as this is)
And, is it possible to take a snapshot according to the versions that I currently have on my machine instead of according to whatever is latest in the DB? (I mean, if i have purposely gotten an older version, when I take the snapshot, I want the older version in my snapshot, not the newer version that I havn't tested)
And, is it possible to take a snapshot according to the versions that I currently have on my machine instead of according to whatever is latest in the DB? (I mean, if i have purposely gotten an older version, when I take the snapshot, I want the older version in my snapshot, not the newer version that I havn't tested)
Snapshot is really the same as Branch, except that it pins it automatically and allows you to hide it from a client's tree. However, it does create new nodes in the tree on the server side, and therefore isn't recommended unless you plan to modify the branch. In fact, it probably makes sense to just us branch. We were going to do away with Snapshot at one point, but decided to keep it as a legacy operation for existing users.
You can branch a historical version of the tree as it exists in the server, just as you can with a label. However, you can't label or branch a specific set of versions that exist only on your client. The initial operation has to be a on a version of a folder that existed at one time on the server.
You can branch a historical version of the tree as it exists in the server, just as you can with a label. However, you can't label or branch a specific set of versions that exist only on your client. The initial operation has to be a on a version of a folder that existed at one time on the server.
The labeling can be done with labeling and label promotion, so it is possible, it's just not a function provided by the client at this time. Branching a promoted label isn't available now, but we talked about that a couple weeks ago, and a request was logged for that feature.However, you can't label or branch a specific set of versions that exist only on your client. The initial operation has to be a on a version of a folder that existed at one time on the server.
This is how CVS tags work, by the way. I would assume SubVersion works that way as well, since it was built as a replacement for CVS.