Some issues and questions

[Hendrik de Goede]

At my company we have been using VSS for some time now. We have been wanting to switch for abuot the same period of time, but just recently i have been asked to compare some candidates to determine what package to use. The packages i am currently 'comparing' are VSS, Vault, Perforce, Team Coherence and Subversion, each having their own advantages i guess.

Now first for some issues i found with Vault.

1) When selecting a previous version from the history dialog and getting that version, the message dialog states it is getting the latest version. The files are retrieved correctly, but it confused me at first. I expected it to state something like 'Getting revision x'.

2) On import (and some other actions that take some time) the message dialog states it's ready when the client actually is still working. What is happening at that point?

And some more general questions.

a) Can somebody state the main differences between the mentioned packages, like performance, maintainability, space usage etc.

b) When using branches, are the so called 'cheap branches'? In other words, are the 'files' actually copied, or just linked to some revision in time?

Hope somebody can help me out here.

[Hendrik de Goede]

Forgot to mention another issue.

When checking in/out a file which contains keywords that need to be expanded, but the file is still open in my editor, the keywords do not get updated (they do in VSS). This is rather a 'big' issue as our release process will generate md5 checkums on all sources. These checksums would not match the version in the database.

Say a file contains $Revision: 5 $ and i have it opened in my editor (EditPlus), i check in my changes, then going back to my editor it still shows $Revision: 5 $. But closing the file, getting the latest version and re-opening the file it would show $Revision: 6 $.

In VSS and Subversion i know the keywords to change immediately, switching to my editor it will show $Revision: 6 $, without having to close it first.

[lbauer]

1) When selecting a previous version from the history dialog and getting that version, the message dialog states it is getting the latest version. The files are retrieved correctly, but it confused me at first. I expected it to state something like 'Getting revision x'.

Yes, we seem to be using the same message in the messages pane whether the get is a latest version or an earlier version. I'll log this as a bug.

However if you have the command dialog for Get enabled in the Vault Client options, the Get dialog will clearly state which version you are getting from history.

2) On import (and some other actions that take some time) the message dialog states it's ready when the client actually is still working. What is happening at that point?

The import tool is working hard to process files and push them to the Vault Server.

And some more general questions.

a) Can somebody state the main differences between the mentioned packages, like performance, maintainability, space usage etc.

We have KB article comparing Vault to SourceSafe:

http://support.sourcegear.com/viewtopic.php?t=659

I'm not as familiar with the other packages you mentioned, but I'd say if you've used VSS, Vault would make an easy transition. Vault is a good value -- the entry price is modest. Another plus -- SourceGear is a relatively small company. We're approachable. We're very responsive to what our customers want and need. We can respond quickly. Many new features in Vault come from requests by our users.

b) When using branches, are the so called 'cheap branches'? In other words, are the 'files' actually copied, or just linked to some revision in time?

In a branch operation, the folder or files are actually copied, so they do take up space in the tree and the database. However you can use labels to mark a file or folder at a particular point in time/version and later do a get by that label.

Hope this helps. I'll leave the keyword issue for a later post.

[Hendrik de Goede]

1) When selecting a previous version from the history dialog and getting that version, the message dialog states it is getting the latest version. The files are retrieved correctly, but it confused me at first. I expected it to state something like 'Getting revision x'.

Yes, we seem to be using the same message in the messages pane whether the get is a latest version or an earlier version. I'll log this as a bug.

However if you have the command dialog for Get enabled in the Vault Client options, the Get dialog will clearly state which version you are getting from history.

Correct, it is hard to make a mistake in getting the wrong version, i just got a little confused by the message at first.

2) On import (and some other actions that take some time) the message dialog states it's ready when the client actually is still working. What is happening at that point?

The import tool is working hard to process files and push them to the Vault Server.

It would be nice, and i think more user friendly, if the client would not say it's finished then. I would like to see from the message dialog what is being done, and when it says it's finished... well i think it should be totally finished. Not a big issue, but like some others i tend to suspect applications to have crashed when they tell me they're finished but still show the sandbox.

And some more general questions.

a) Can somebody state the main differences between the mentioned packages, like performance, maintainability, space usage etc.

We have KB article comparing Vault to SourceSafe:

http://support.sourcegear.com/viewtopic.php?t=659

I'm not as familiar with the other packages you mentioned, but I'd say if you've used VSS, Vault would make an easy transition. Vault is a good value -- the entry price is modest. Another plus -- SourceGear is a relatively small company. We're approachable. We're very responsive to what our customers want and need. We can respond quickly. Many new features in Vault come from requests by our users.

Agreed, working with Vault is very easy when you're used to VSS (better yet it's just easy to work with), and yes, the price is right. It's just that it's hard to compare all these products, and so far the internet hasn't been of much help to me, as in providing 'detailed' comparisons of the various products. I guess i'll have to look harder.

b) When using branches, are the so called 'cheap branches'? In other words, are the 'files' actually copied, or just linked to some revision in time?

In a branch operation, the folder or files are actually copied, so they do take up space in the tree and the database. However you can use labels to mark a file or folder at a particular point in time/version and later do a get by that label.

I'm afraid labels won't do for our company. We have several 'frameworks' (about 10) all using the same version numbers style, labels have to be unique against a complete 'repository'. I guess we should consider our version labels to contain some framework identifier then. The same would be for the 'main' projects (about 20 now, 1 to 2 newly added per week). Or is there a better way? A single framework is about 600 files and 15mb in size, but most files tend to stay the same during development. We want to use released versions, and we want to have them in our source control package. Branching seems most likely, but branching the entire tree seems so expensive to me when only about 20 files changed.

Hope this helps. I'll leave the keyword issue for a later post.

Yes it did help me, thanx. Hope to see the next post soon as that is what's holding me back a bit at the moment.

[jclausius]

We have several 'frameworks' (about 10) all using the same version numbers style, labels have to be unique against a complete 'repository'.

Can you elaborate here?

While Vault does have a unique constraint on a label for a given object's version, Vault does not place restrictions related to the uniqueness of a label within a repository. From what you described, if each framework involves its own objects, then re-using the same label is not a problem.

Ex: 'RTM 1.0' could be applied over and over to multiple, distinct objects throughout the repository.

[lbauer]

To get back to your other issue of Keyword Expansion:

Forgot to mention another issue.

When checking in/out a file which contains keywords that need to be expanded, but the file is still open in my editor, the keywords do not get updated (they do in VSS). This is rather a 'big' issue as our release process will generate md5 checkums on all sources. These checksums would not match the version in the database.

Say a file contains $Revision: 5 $ and i have it opened in my editor (EditPlus), i check in my changes, then going back to my editor it still shows $Revision: 5 $. But closing the file, getting the latest version and re-opening the file it would show $Revision: 6 $.

In VSS and Subversion i know the keywords to change immediately, switching to my editor it will show $Revision: 6 $, without having to close it first.

I'm not familiar with EditPlus, but when I used Notepad, the keyword in my open text file did not change after checkin until I re-opened the file (I didn't have to get the latest version). This was the same behavior in VSS and Vault. I'm not sure why this works differently in EditPlus. We designed Vault keyword expansion behavior to be similar to VSS behavior.

[Hendrik de Goede]

We have several 'frameworks' (about 10) all using the same version numbers style, labels have to be unique against a complete 'repository'.

Can you elaborate here?

While Vault does have a unique constraint on a label for a given object's version, Vault does not place restrictions related to the uniqueness of a label within a repository. From what you described, if each framework involves its own objects, then re-using the same label is not a problem.

Ex: 'RTM 1.0' could be applied over and over to multiple, distinct objects throughout the repository.

Placing labels won't do, we might want to fix some bugs on a previous framework and release (branch) a bugfix version. Some old projects might use an old framework, and sometimes it's just too much work to upgrade the project to the latest framework, where a simple bugfix would do.

To get back to your other issue of Keyword Expansion:

Forgot to mention another issue.

When checking in/out a file which contains keywords that need to be expanded, but the file is still open in my editor, the keywords do not get updated (they do in VSS). This is rather a 'big' issue as our release process will generate md5 checkums on all sources. These checksums would not match the version in the database.

Say a file contains $Revision: 5 $ and i have it opened in my editor (EditPlus), i check in my changes, then going back to my editor it still shows $Revision: 5 $. But closing the file, getting the latest version and re-opening the file it would show $Revision: 6 $.

In VSS and Subversion i know the keywords to change immediately, switching to my editor it will show $Revision: 6 $, without having to close it first.

I'm not familiar with EditPlus, but when I used Notepad, the keyword in my open text file did not change after checkin until I re-opened the file (I didn't have to get the latest version). This was the same behavior in VSS and Vault. I'm not sure why this works differently in EditPlus. We designed Vault keyword expansion behavior to be similar to VSS behavior.

Notepad doesn't detect file changes by other programs, most other editor do. When i have a file opened in editplus and check in the file in VSS, going back to editplus it will show me a popup informing me the file was changed outside editplus. Often editors allow you to select wether or not to be informed about this, or just reload the file. Notepad is totally unaware of any outside changes to files, that's why using notepad you will not see any difference in behaviour when comparing VSS and Vault.

[Hendrik de Goede]

b) When using branches, are the so called 'cheap branches'? In other words, are the 'files' actually copied, or just linked to some revision in time?

In a branch operation, the folder or files are actually copied, so they do take up space in the tree and the database.

Are you really sure? Just did a double check, the database size as reported by the admin tool does not increase on branches, also the process of creating a branch is rather short, so... i think branches are cheap in Vault, or am i assuming wrong?

[jclausius]

Placing labels won't do, we might want to fix some bugs on a previous framework and release (branch) a bugfix version. Some old projects might use an old framework, and sometimes it's just too much work to upgrade the project to the latest framework, where a simple bugfix would do.

Wouldn't promoting a file's version within the Label work? Perhaps not. You know the details of your process better than I do. One other thing to bring up - Have you investigated Vault's Snapshot feature?

Just did a double check, the database size as reported by the admin tool does not increase on branches, also the process of creating a branch is rather short, so... i think branches are cheap in Vault, or am i assuming wrong?

In a way, you are both correct... from a certain point of view.

In Vault 1.0.x, the copy was made immediately on a branch.

However, this was later modified to eliminate repository bloat. So, later releases, including Vault 2.0.3, create "references" to source files for both branched and snapshot items. Only when the file is modified will a copy of the source file be created within the database.