Help with Branching Part 2

[rbanerji]

Continuing from my original post. Failing to load a solution that was moved from one repository to another, I decided another approach (actually, I tried this first and then the dual repository approach )

- So I have a solution with several projects in repository_1 with a working folder of folder_1.
- I create a share to solution folder and hence all sub folders in source vault. Lets call this sub tree shared_folder_1.
- I pin all the files in this share. (by the way, pinning a folder does not pin the files in the folder. Whats with that? Also pinning a folder, obvioulsy, does not recursively pin files in all sub folders. Whats with that?). So I painfully go folder by folder and pin the files. By a stroke of luck one can select all files and pin them
- now I carry on writing new code in the original folders, i.e., folder_1.
- Then one day, I open the VS IDE, I say open solution from source control, I select the solution in the shared_folder_1.
- The solution opens fine, but hey!!!!!!!!!!!!, its not the pinned version of the code. Its the latest code. What just happened?

I have been battling this for a while. Is there anyone there who can help I am hoping it is I who is making a mistake. Would really suck if the software is so buggy.

Thanks.

[rbanerji]

I forgot to add that if I do a get latest on shared_folder_1 I get the pinned version. Its just the VS IDE and open from source control that seems to ignore the pin.

[jclausius]

(B)y the way, pinning a folder does not pin the files in the folder. Whats with that? Also pinning a folder, obvioulsy, does not recursively pin files in all sub folders. Whats with that?).

"You must unlearn what you have learned" about VSS. VSS does not support folder pin, so you'll have to consider the actions of a pinned folder.

When you pin a folder, it is the only true object which is pinned, thus the only object in which you can unpin; ergo, the object receives a pin icon.

However, the system is designed that no object can be modified under a pinned folder. These items are considered "secondarily pinned". The objects are not pinned themselves (not receiving the pin icon), but belong as a set of a pinned folder.

So I painfully go folder by folder and pin the files. By a stroke of luck one can select all files and pin them

This is a bit more tedious, and you may achieve your initial goal. But it is still possible to modify the contents of the folder by adding a new file / folder. The only way you can guarantee a folder will not change is to pin the folder itself.

- now I carry on writing new code in the original folders, i.e., folder_1.
- Then one day, I open the VS IDE, I say open solution from source control, I select the solution in the shared_folder_1.
- The solution opens fine, but hey!!!!!!!!!!!!, its not the pinned version of the code. Its the latest code. What just happened?

Remeber VS.Net is going to look at the files on disk. After doing the pins, you'll need to get (w/ overwrite if needed) the pinned files to synchronize your local files with that of the repository. I reckon your files were still the latest files, and not the pinned versions themselves.

Thanks.

Your welcome.

[Guest]

Jeff,

Thanks for your reply. Here are some of the issues. The problem with pinning a folder and not all files is that if I pin a folder, I can not unpin a single file, make a change to it and pin it again. I have to unpin the folder to change a single file. The moment I unpin the folder all files in that folder now have the latest version of the code, i.e., I cannot isolate a single file for change while retaining the pinned versions for all other files. And hence I have to go through the painful task of pinning the files. Perhaps you should offer an option when pinning a folder to letting the user choose between truly pinning a folder as you have right now and doing a recursive file pin.

rbanerji wrote:
- now I carry on writing new code in the original folders, i.e., folder_1.
- Then one day, I open the VS IDE, I say open solution from source control, I select the solution in the shared_folder_1.
- The solution opens fine, but hey!!!!!!!!!!!!, its not the pinned version of the code. Its the latest code. What just happened?

You responded:
Remeber VS.Net is going to look at the files on disk. After doing the pins, you'll need to get (w/ overwrite if needed) the pinned files to synchronize your local files with that of the repository. I reckon your files were still the latest files, and not the pinned versions themselves.

No, I am opening a solution from Source Control to a new location. So there are no files period. Yet it gets me the latest version and not the pinned version. Then I do a get latest latest with override tto sync up the files. Just a pain.

Thanks.

[Guest]

Hi Jeff,
I'd like to draw similarity with the comment posted here and the problems I'm having with figuring how to maintain what goes into a release candidate.

"To modify a secondary pinned item you must remove the primary pin on the containing folder". This means that you can't use sharing and pinning as a way of creating a "light-weight" branch for a release candidate. As posted here, when you remove the pin from the primary folder you get all the latest versions from the share. Not what you want to happen for a release candidate. This means that the only way to maintain a release candidate that you're going be tweaking and writing hot fixes for is to do a branch. I believe from the posts in this forum that branching won't scale, as the repository will soon bloat.

Thanks
Christian

[jclausius]

Jeff,

Thanks for your reply. Here are some of the issues. The problem with pinning a folder and not all files is that if I pin a folder, I can not unpin a single file, make a change to it and pin it again. I have to unpin the folder to change a single file. The moment I unpin the folder all files in that folder now have the latest version of the code, i.e., I cannot isolate a single file for change while retaining the pinned versions for all other files. And hence I have to go through the painful task of pinning the files. Perhaps you should offer an option when pinning a folder to letting the user choose between truly pinning a folder as you have right now and doing a recursive file pin.

If you are wanting to make individual changes to a small number of files within the folder, then I can see how Folder Pin can present a problem.

I don't recall if I mentioned this in the other post, but have you looked at snapshot? The newly created files within the snapshot are branched, so their contents are the same as the folder which was snapshot.

In any case, I've created a customer feature request related to "recursive" file pin.

- now I carry on writing new code in the original folders, i.e., folder_1.
- Then one day, I open the VS IDE, I say open solution from source control, I select the solution in the shared_folder_1.
- The solution opens fine, but hey!!!!!!!!!!!!, its not the pinned version of the code. Its the latest code. What just happened?

You responded:
Remeber VS.Net is going to look at the files on disk. After doing the pins, you'll need to get (w/ overwrite if needed) the pinned files to synchronize your local files with that of the repository. I reckon your files were still the latest files, and not the pinned versions themselves.

No, I am opening a solution from Source Control to a new location. So there are no files period. Yet it gets me the latest version and not the pinned version. Then I do a get latest latest with override tto sync up the files. Just a pain.

That does sound strange. I'll investigate this some more to see exactly what is going on.

[jclausius]

This means that you can't use sharing and pinning as a way of creating a "light-weight" branch for a release candidate. As posted here, when you remove the pin from the primary folder you get all the latest versions from the share. Not what you want to happen for a release candidate.

Yes, that is true. I would recommend using Snapshot in this case.

This means that the only way to maintain a release candidate that you're going be tweaking and writing hot fixes for is to do a branch. I believe from the posts in this forum that branching won't scale, as the repository will soon bloat.

Can you define "bloat"?

From a tree standpoint, either sharing from history or branching (snapshot) will introduce new nodes into the tree. So, the tree itself will grow (bloat) in either case.

However, branching / snapshots are light-weight in nature, so these new tree nodes do not consume any new storage on disk for their files, as each node uses a back-reference to the original node. No new storage is clained for the source files.

[Guest]

Hi Jeff,
When I say "bloat" I was thinking in terms of an increase in the physical size of the tree in terms of disk space. I understand that there is a trade-off between having a single repository which gives you more options for sharing, branching etc, versus multiple repositories that give you better performance as it reduces the tree in each that has to be traversed on actions such as check-out.
However, I think its a combination of thinking Vault works like Src safe when you do a branch (ie it physically creates a new set of nodes for the branch) and me "reading in between the lines" and making 2 + 2 = 5!!
Thank you for making the position clearer.

Up till now I've really dismissed snapshots as a feature after reading the help files, and I quote:
"It is recommended that you use branches or labels to mark a version of a tree. Snapshots are simply a historical oddity."

Just to make sure I'm not misreading (again!!) can you confirm that...

Snapshot, is a Vault feature that is recommended and will be supported going forward
A snapshot AND copy branch AND share branch all create a "lightweight branch" ie do not consume any new storage on disk for their files.
Creating a branch (either a share, copy or snapshot) will not degrade performance of Vault operations such as a checkout.

Thanks

PS I apologise for somewhat hijacking the original posters topic!

[jclausius]

Up till now I've really dismissed snapshots as a feature after reading the help files, and I quote:
"It is recommended that you use branches or labels to mark a version of a tree. Snapshots are simply a historical oddity."

Just to make sure I'm not misreading (again!!) can you confirm that...

Snapshot, is a Vault feature that is recommended and will be supported going forward

Snapshot Recommended...
To be honest, I would recommend the following operations:
1) Label when you reach a desired point in time. Consider a label as a shortcut to a "view of the past".
2) Branch the label when you determine it is time to make changes. View a branched label as a light-weight copy, in which you will be making modifications in the immediate future.

Snapshot Supported...
While not the recommended procedure, I don't think Snapshot will disappear from Vault anytime soon.

A snapshot AND copy branch AND share branch all create a "lightweight branch" ie do not consume any new storage on disk for their files.

Correct.

Creating a branch (either a share, copy or snapshot) will not degrade performance of Vault operations such as a checkout.

There might be some small differences of a Shared Folder vs. Branched Folder, since a branch folder creates new objects w/ reference pointers to the old files. But I believe the differences would be negligible.

[jclausius]

Jeff,

Thanks for your reply. Here are some of the issues. The problem with pinning a folder and not all files is that if I pin a folder, I can not unpin a single file, make a change to it and pin it again. I have to unpin the folder to change a single file. The moment I unpin the folder all files in that folder now have the latest version of the code, i.e., I cannot isolate a single file for change while retaining the pinned versions for all other files. And hence I have to go through the painful task of pinning the files. Perhaps you should offer an option when pinning a folder to letting the user choose between truly pinning a folder as you have right now and doing a recursive file pin.

If you are wanting to make individual changes to a small number of files within the folder, then I can see how Folder Pin can present a problem.

I don't recall if I mentioned this in the other post, but have you looked at snapshot? The newly created files within the snapshot are branched, so their contents are the same as the folder which was snapshot.

In any case, I've created a customer feature request related to "recursive" file pin.

- now I carry on writing new code in the original folders, i.e., folder_1.
- Then one day, I open the VS IDE, I say open solution from source control, I select the solution in the shared_folder_1.
- The solution opens fine, but hey!!!!!!!!!!!!, its not the pinned version of the code. Its the latest code. What just happened?

You responded:
Remeber VS.Net is going to look at the files on disk. After doing the pins, you'll need to get (w/ overwrite if needed) the pinned files to synchronize your local files with that of the repository. I reckon your files were still the latest files, and not the pinned versions themselves.

No, I am opening a solution from Source Control to a new location. So there are no files period. Yet it gets me the latest version and not the pinned version. Then I do a get latest latest with override tto sync up the files. Just a pain.

That does sound strange. I'll investigate this some more to see exactly what is going on.

I ran a test last night, and did not encounter any problems with pin and Vault's IDE client.

Here are the steps I used in my test:

• Created a test Console based application.
• Added the entire solution to Vault
• Checked out class1.cs, modified the file (added line "should be version 2", and check the file back in.
• Checked out class1.cs, modified the file (added line "should be version 3", and check the file back in.
• Closed VS.Net 2003
• Deleted the entire directory for the local copy of the Console based app.

Next:

• Logged into Vault, and pinned class1.cs back to version 1
• Restarted VS.Net 2003
• Invoked Open From Source Code Control. VS.Net asked for new working folder locations, which I set to a new path.
• After VS.Net had finished opening the project, I examined the file class1.cs. It was the safe file as Version 1.
• I then invoked File->Source Control->SourceGear Properties to verify the file was "Pinned at version 1", and my Local Copy was Version 1.
• Switched back into Vault. The class1.cs file is still version 1. I unpinned the file.
• Switched back to VS.Net 2003. and looked at the SourceGear Properties. This dialog says my file is now Old and still at Version 1. However the repository version is unpinned and at version 3.
• Did a Get latest on the file.
• The file's contents changed to include Version 3's text. The SourceGear Properties also showed my local copy was updated to version 3.

One thing comes to mind. You mention you opened a solution from a "shared" location. Where did the "shared" location come from? Once a project is added to Vault, VS.Net stores information to the repository path within the solution / project files.

If the solution was created from an already existing Vault bound project, did you re-bind this solution to point to new location of the pinned files? If not, that would explain why the "shared" solution pointed back to the original files - VS.Net stored the original Repository path, which was not updated.

[christian]

Thanks for all the info and advise.

Snapshot Recommended...
To be honest, I would recommend the following operations:
1) Label when you reach a desired point in time. Consider a label as a shortcut to a "view of the past".
2) Branch the label when you determine it is time to make changes. View a branched label as a light-weight copy, in which you will be making modifications in the immediate future.

Ok, I think I'm going to label and then branch at the label to contain work for a hotfix. As to being able to tweak the contents of the label using label promotion before branching: I'll wait until you've added that to vault as an enhancement :-)

[jclausius]

Thanks for all the info and advise.

No problem

Ok, I think I'm going to label and then branch at the label to contain work for a hotfix. As to being able to tweak the contents of the label using label promotion before branching: I'll wait until you've added that to vault as an enhancement

I agree. I think using labels as a historical view is the right approach.