Vault and Shared Files
Moderator: SourceGear
Vault and Shared Files
Hi,
Shared files have been a point of discussion for some time now and we cannot go ahead with our migration to Vault until it has been solved. We will be storing Delphi code in Vault (which is still used everyday) and ASP.NET C# for all our new products. The best way I can describe the problem is through a scenario.
Bob is writing a project which requires some shared files to be included in the project. He pulls the shared files into his library and references them. Meanwhile Pete is starting a project which requires the same shared files but some amendments need to be made. Pete makes the amendments to the shared files and therefore also updates Bob's copy because the shared files are linked. The result is that Bob finds that his code no longer works because the shared files have changed. Bob might also face a problem if he has finished a project and it is in Vault waiting to be built to go live and someone makes a change to the shared files which again breaks Bob's code.
How do we successfully deal with shared code??
Any help or suggestions with this would be greatly appreciated.
Thanks very much
Dave
Shared files have been a point of discussion for some time now and we cannot go ahead with our migration to Vault until it has been solved. We will be storing Delphi code in Vault (which is still used everyday) and ASP.NET C# for all our new products. The best way I can describe the problem is through a scenario.
Bob is writing a project which requires some shared files to be included in the project. He pulls the shared files into his library and references them. Meanwhile Pete is starting a project which requires the same shared files but some amendments need to be made. Pete makes the amendments to the shared files and therefore also updates Bob's copy because the shared files are linked. The result is that Bob finds that his code no longer works because the shared files have changed. Bob might also face a problem if he has finished a project and it is in Vault waiting to be built to go live and someone makes a change to the shared files which again breaks Bob's code.
How do we successfully deal with shared code??
Any help or suggestions with this would be greatly appreciated.
Thanks very much
Dave
Dave:
Assuming Bob is still working on the project, and needs to keep the shared files at a known version, then he would pin the shared files to the desired version.
Do you want to keep the files shared for later use? If not, the share link could be broken by having Bob branch the shared files. This way as Pete makes changes, Bob is unaffected.
Finally, when Bob reaches a stable point where no other changes are taking place, he can pin the folder itself or make a label on the folder which will freeze ALL files at their current version.
HTH
Assuming Bob is still working on the project, and needs to keep the shared files at a known version, then he would pin the shared files to the desired version.
Do you want to keep the files shared for later use? If not, the share link could be broken by having Bob branch the shared files. This way as Pete makes changes, Bob is unaffected.
Finally, when Bob reaches a stable point where no other changes are taking place, he can pin the folder itself or make a label on the folder which will freeze ALL files at their current version.
HTH
Jeff Clausius
SourceGear
SourceGear
It souds like this should be a branch instead of a share, if the underlying code is changing.
For instance:
$/library1_trunk/code
could be a place to keep your stable version of the library, that everyone shares from. Anyone who wants to link to the stable version should link to here.
If Pete is changing the code, he should branch it first:
$/library1_dev/code
When Pete is done with his changes and the library has been tested, use the Merge Branches wizard to move all the changes from the dev branch into the trunk. Then everyone will be using the updated, tested version.
If you have multiple projects, all of which need different versions of the library, the only way to handle that would be to have different branches in the tree that are stable for each version.
Hope this helps,
For instance:
$/library1_trunk/code
could be a place to keep your stable version of the library, that everyone shares from. Anyone who wants to link to the stable version should link to here.
If Pete is changing the code, he should branch it first:
$/library1_dev/code
When Pete is done with his changes and the library has been tested, use the Merge Branches wizard to move all the changes from the dev branch into the trunk. Then everyone will be using the updated, tested version.
If you have multiple projects, all of which need different versions of the library, the only way to handle that would be to have different branches in the tree that are stable for each version.
Hope this helps,
Thank very much for replying so quickly Jeff.
Pinning sounds like a good solution to this problem, but what would happen if Bob needed to make changes to the shared files after Pete has?
If he unpinned them and made changes, would it automatically pick up the changes that Pete has made and would this also affect Pete??
I am beginning to wonder whether sharing is suitable in this scenario or whether some kind of branching would be more suitable because it seems we might need to some how merged the changed shared files back together?
You help with this is hugely appreciated.
Thanks again
Pinning sounds like a good solution to this problem, but what would happen if Bob needed to make changes to the shared files after Pete has?
If he unpinned them and made changes, would it automatically pick up the changes that Pete has made and would this also affect Pete??
I am beginning to wonder whether sharing is suitable in this scenario or whether some kind of branching would be more suitable because it seems we might need to some how merged the changed shared files back together?
You help with this is hugely appreciated.
Thanks again
If Bob needs to make changes, then I would suggest looking along the lines of Dan's suggestion regarding branches.davecourt wrote:Thank very much for replying so quickly Jeff.
Pinning sounds like a good solution to this problem, but what would happen if Bob needed to make changes to the shared files after Pete has?
If he unpinned them and made changes, would it automatically pick up the changes that Pete has made and would this also affect Pete??
I am beginning to wonder whether sharing is suitable in this scenario or whether some kind of branching would be more suitable because it seems we might need to some how merged the changed shared files back together?
You help with this is hugely appreciated.
Thanks again
Jeff Clausius
SourceGear
SourceGear