Branching issue

[asills]

I recently imported my VSS database and everything worked pretty good (a few labels weren't able to be added, but they were useless anyway).

I go to branch a project today from a label, but when I do it the branch contains all the new changes after the label. Note the attached screenshot, when I choose the v1.0.1 label and branch it, I get all of the changes after the date of the branch.

Any ideas?

[asills]

Okay, here's what we are seeing. I finished the SS import on 1/30.

If I do a show labels I can see a label for Version 349 on 1/19 called v1.0.1.

http://www.surrealization.com/files/adam/vault/pic1.png

If I View the label, I can see that it has the correct version of everything in it (specifically, there's a file called AleDataStore.cs that shouldn't be there).

http://www.surrealization.com/files/adam/vault/pic2.png

If I view history of the project I can see the AleDataStore.cs file was added on 1/28.

http://www.surrealization.com/files/adam/vault/pic3.png

Notice the above, the folder "Globeranger.EdgeSerivces.Ale.Runtime" was labeled on version 349. If I view history (by version not by item) and branch off of Version 349 and view the branch I can see the new file in there!

(view by history)
http://www.surrealization.com/files/adam/vault/pic4.png
(the branch)
http://www.surrealization.com/files/adam/vault/pic5.png

Viewing the csproj file I can see that it is a new version and not an old version.

The only thing that's NOT in the new branch is a file I added today called test.txt:

(the location I branched FROM)
http://www.surrealization.com/files/adam/vault/pic6.png
(the location I branched TO)
http://www.surrealization.com/files/adam/vault/pic7.png

It looks like it's using the date of the folder version 349 to decide what to branch (version 349 was the date the label was created by the import tool, but the label was technically created for 1/19, which is shown when you do a show labels).

(showing 1/29)
http://www.surrealization.com/files/adam/vault/pic4.png
(showing 1/19)
http://www.surrealization.com/files/adam/vault/pic1.png

This is basically preventing us from branching on one of the labels we created when we used SourceSafe. Is there something I can do to fix this? Is what I'm saying making any sense?

[jeremy_sg]

Adam,

There's quite a few things going on. Email me your phone number using the button below this post and I'll call you.

[jeremy_sg]

Talking to asills cleared up a few things. All his problems were related to try to branch imported labels. Unfortunately, this is not going to work due to the tricks that Vault has to do to get VSS labels into Vault. The emphasis has always been to make sure that when a label is downloaded from Vault and VSS that the contents match exactly. That principle made it necessary to compromise on the ability to branch imported labels. All regular Vault labels going forward can be branched as normal.

[asills]

And to further clarify for Jeremy and hopefully anyone else who happens upon this, the way the SourceSafe import works (one file at a time, then at the very end the labels) causes all labels to get the highest version number of the folder:

Folder Version
--------------------------
Folder1 300 Checked in file X (1/1/2004)
Folder1 150 Added file X (3/30/2002)
...
Folder1 300 Labeled v1.0.0 (3/1/2002)
...
Folder1 2 Checked in file Y (1/2/2002)
Folder1 1 Added file Y (1/1/2002)

That label (v1.0.0) contains the correcct versions of all of the files, however when you branch off of a label it uses the version number you are branching from to create the branch. Since all of my labels have the same version (300), the branch is created off of that version.

This is just the way the import works. It processes each folder one file at a time, so it creates every version of every file one file at a time; this means that if your folder contains 5 files, it does every version of the first file before moving to the second file. Thus, your folder version rapidly changes and doesn't exactly mimic reality (which isn't really a problem, since SourceSafe really didn't have the concept of folder version anyway).

The way Vault branches a folder, it uses the version number of a folder to determine what to include in the branch. This is the main problem, since the imported folder versions at the point of the label represent the current version of the folder (because again, the files were done one at a time so there is no folder version that can indicate the contents of the label; unless, of course you only had a single file in the folder).

What really gets me, however, is the fact that I can fetch the label perfectly, but branching off of a label still goes by folder version. I would love to add a feature request that if you selected a label as the source of your branch, it should find the versions of the files that relate to that label (which it already can do) and create the branch from that, and ignore the folder version (and if you are branching not from a label, it should work just as it does now).

In my case, we don't have a lot of need for complex branching at the moment, so just creating a copy of the files as they exist in the label works well enough and our developers will just have to add their code to both places.

[jclausius]

I would love to add a feature request that if you selected a label as the source of your branch, it should find the versions of the files that relate to that label (which it already can do) and create the branch from that, and ignore the folder version (and if you are branching not from a label, it should work just as it does now).

I believe there is already a request for this feature. I've added your name to the user's requesting this functionality.

[GregM]

This same problem happens if you use label promotion. The branch created from that label is incorrect, as it just uses the version of the folder at the time the label was created. That's probably where the request that JC is referring to came from.

[asills]

Yeah but hasn't everyone read Eric Sink's novella on source control and agreed with his opinion that label promotion is bad?

[GregM]

Apparently the people at SourceGear haven't, because they include label promotion in their product...

[jeremy_sg]

Yes, it's true. The way we import VSS labels is by promoting a label until the contents match exactly what VSS has. Yes, label promotion is bad, but in the case of VSS import (since VSS doesn't have folder versions) it is unavoidable. When we add the ability to branch a promoted label, it will fix the issue with imported labels as well.

[jclausius]

Apparently the people at SourceGear haven't, because they include label promotion in their product...

Touche'. In actuality, for good or bad Vault's feature set is decided by customers.

For example, the original release of Vault was not going to support Pin/Share. Can you imagine the feedback we would have received if this would have been the case? Things would have been bad. Customer feedback prevailed, so the features did make Vault 1.0.

To be honest, I feel responding/adding customer requests is one of the major contributing factors making Vault the success it is today.

[GregM]

Yeah, I know all about that. I've added my share of functions that I felt had no business in the product, but that users desparately wanted.

Now, there are good uses for label promotion that don't involve loss of history (if only to cover for missing features in Vault). For example, it is impossible to create a branch from an arbitrary set of file revisions. With label promotion, you can create the label on the files you need, and branch from there (at least, you could if it worked properly). If you could "create a label containing the revisions of the files as I last retrieved them from the server", then you could verify that this is the set of files as you want them in the branch, create the label so you have a good point from which to branch, and branch from that label. There you go, you just removed a need for label promotion.

[GregM]

Also, if you could label an arbitrary collection of file revisions, then you wouldn't need to use label promotion during VSS Import as well.

Of course, this assumes that only reason that "Label Promotion is bad" is becase as Eric describes, it allows you to change history, and not that "it labels a group of file revisions that never existed at the same time in the history of the tree."

For the record, I agree that revisionist history by label promotion is "bad", but not being able to label arbitrary revisions is "worse", and so I'll live with "bad" until "worse" is fixed.