Version of local files

[Ralf]

Is it possible to retrieve the version of the files that are on a local machine?
In history I can see a version number (serverside) for a folder that increments with each checkin below that folder.
Is it possible to see that version number for a local file structure?
Suppose a folder A has version 55 and I get the latest version. Other people may perform checkins that increment the version number.
Is it still possible for me to see that my local structure is updated until version 55?

[Beth]

If someone else checks in a file, then the status of that file will change for you. If you have not modified the file already, then the status will change to Old. If you have modified the file, the status will change to Needs Merge.

If you just want to verify which version number you have on disk, you can right-click the file inside of Vault and select Show Differences. You will want to compare it to the current version in the repository. If you want to compare it to an older version, then you will Show History on the file first, then right-click the version to compare against and select Diff.

[Ralf]

Thanks for the reply.

I actually need the version of a folder (not of a file). My goal is the following:
I have a build task that determines which version my local source is.
This version is generated into a AssemblyInfo.cs file and compiled with the build.
This way I have the exact version number for the whole project compiled into the assembly.
But now I take the version for a folder from the server. So if I check out some code and at a later stage compile it (and in meantime other people checkin changes),
the version number is not correct. Or another case, when I get an old version from Vault and compile it, I need the version number of that old version.

Goal is to have and exact reference inside the compiled assembly that reflects the source that was used for it.

[Beth]

You might try using labels to mark the folders and the label will then be associated with the folder version number. After that, you can perform any manipulation you need based on labels, including Gets and Diffs.

Are you checking in changes that are performed to those older versions? If so, then we should maybe discuss branching as well.

Some articles that explain how we work are posted in the following:
Eric Sink's Source Control How To
Best Practices for Managing Branches
Basics of using Label, Cloak, Share, Pin, Branch and Merging
How to label as part of a build script

[Ralf]

When working with labels, does a local checkout know which label it is?
So, if the current label for a folder on the server is for example "Version 1.5" and I checkout the previous label "Version 1.4", am I able to "see" that my local files are "Version 1.4"?

[Beth]

You won't see the label listed as what you have on disk. If you look in your Vault GUI client, you will see the individual file versions and you well see what you have on disk doesn't match what is in Vault. What labels will provide you is an easy way to refer to some of the folder versions that are important to you for building older versions. Rather than trying to determine the version on disk, you could perform a Get on a label that represents what you want to build.

Goal is to have and exact reference inside the compiled assembly that reflects the source that was used for it.

A label is an entity that lists all the exact source versions that are a part of it. You can also view a label to see what file versions are in it, you can see what folder version it was placed on in history, and if something isn't quite right in a label, you can change the file versions that are in it.

[Ralf]

I know how labels work.
So, there is no way of automatically having some marker (label, version or whatever) in the output assembly at the moment of building?
As I understand, the only way is to extract a label with a GET to a separate folder and use for example the foldername to identify the marker?

Pitty. I've used subversion before and it keeps track of the version of local folders (the version number shown in show history)...
This might be due to technical differences between subversion and vault.

[Ralf]

BTW : we're using version 4.1.4. Maybe something changed in version 5?

[Beth]

You can view the folder version number in history. I'm not sure how that's going to help you though.

After you invoke Show History, a window will pop up with options. Select the option to 'view folder history by version.' That shows each folder version.

[Ralf]

Yes, but that's the current server version number. I would like the version of the files I have on my local system (at the moment of building).
This would generate an exact reference to "something" in Vault which makes you able to retrieve the exact source it was build with (if you don't have pending changes).

[Beth]

I would like the version of the files I have on my local system

The individual file versions on disk are shown in the Vault GUI client. The folder version on disk isn't shown.

which makes you able to retrieve the exact source it was build with

If I understand this correctly, your ultimate goal is to make sure you have the correct file versions for a build. That's why I suggested labeling. If you had a label that contained all the file versions you need for a build, then you can Get it to disk and know after that Get that you have all the file versions you need. If you needed to double-check it, then you would diff on the labels.

As far as showing the folder version on disk, I could take a feature request. It wouldn't help you immediately, but taking a feature request would make the developers aware that someone wants that ability.

[Ralf]

I would like the version of the files I have on my local system

The individual file versions on disk are shown in the Vault GUI client. The folder version on disk isn't shown.

But am I able to retrieve this in a build task? Using the client API?

which makes you able to retrieve the exact source it was build with

If I understand this correctly, your ultimate goal is to make sure you have the correct file versions for a build. That's why I suggested labeling. If you had a label that contained all the file versions you need for a build, then you can Get it to disk and know after that Get that you have all the file versions you need. If you needed to double-check it, then you would diff on the labels.

The ultimate goal is the following:
Let a developer get "some" (possibly old) version of a folder from Vault.
Build it on the local machine.
The output assembly should contain "something" that indicates exactly which source it is built with (label, version or whatever).
As far as I understand there is no way of determint the label (or version) for a local folder on your system.

As far as showing the folder version on disk, I could take a feature request. It wouldn't help you immediately, but taking a feature request would make the developers aware that someone wants that ability.

Adding a feature request would be great (and let the client API support retrieving it)!

Thanks

[jclausius]

Ralf,

I'm stepping in on Beth. There are a couple of different ways to tackle this problem:

a) Labeling the Folder (Tagging) - With this method you would first apply a label to a given folder (or set of folders) at any version you wish. Then using the command line client (or using a tool or some other software integrated with Vault), GET the label's content to disk. Once the files have been retrieved, the build process takes over and produces binary output.

One advantage here is if you have a label or "tag" within the Vault repository of when that build actually occurred. And in most cases, incremental build numbers can be utilized to be a part of the label, so it is easy to see at a glance when a build occurred and which source code files were used in that build.

b) Getting on a Folder Version - With this method, you would use the GUI client or the API ( with either a known folder's versioned, skeleton and ClientInstance.GetByDisplayVersion() or a folder itself and ClientInstance.GetByDisplayVersionToNonWorkingFolder()) to GET the folder's contents at a known version. Similar to step A, once the files have been retrieved, the build process takes over.

One disadvantage to this method would be, from Vault's viewpoint, there is no indication from that any event occurred, and here indication that this group of files participated in that event. To get all the information, you would need to know the version of the BUILD to identify which version of the folder contained those files.


In sum, either method will work. It just depends if you want some kind of record an event occurred, and if you want to identify a group of files that were a part of that event.

In regards to earlier posts regarding folder versions, you can always "GET" the files of a versioned folder, and while the files would be there, there is no indication within the GUI client what folder version is on disk. But for building that may not be important.