Hi guys,
I've been tasked with automating the steps that we need to perform whenever we do a branch (such as incrementing an ini file containing version numbers for the trunk, labelling the trunk and branch, etc).
To do this I want to use the BRANCH command. Problem is most of our branches are created for a historical version of the trunk and the BRANCH command doesn't have a switch to specify the version of the truck (ie Vault folder) that is to be branched.
Is it possible to add this functionality to the command line, say in the next 5-6 weeks (ie I'm hoping 5-6 wks is a reasonable amount of time for you guys)?
Thanks
Christian
Branch from history using the command-line
Moderator: SourceGear
I'll add this as a feature request, but it isn't likely to get done in the next 5-6 weeks. The command line client source is available, so if it is critical for you, you can always get it done that way.
One question though: If you branch a specific version of a folder, how would you know which version you want to branch?
One question though: If you branch a specific version of a folder, how would you know which version you want to branch?
Hi Dan,
Ok, so the source code is available - I add the source code to say the following folder $/ThirdpartyCode/Sourcegear/CLC. Branch this so as to keep my changes separate from your changes to give:
$/ThirdpartyCode/Sourcegear/CLC
$/ThirdpartyCode/Sourcegear/Branches/CLC
Assuming the next version you release does not include this additional functionality I then need to merge our code changes with this latest version.
Now this merge may or may or not go smoothly - it depends on whether there decent support in Vault for a Vendor drop (cvs feature) in maybe the form of a wizard (see http://support.sourcegear.com/viewtopic ... endor+drop)
I know you guys will be busy (who's not) but supporting customisations to third party source code is a real pain in the arse particularly when it looks unlikely that Vault is going to get functionality (Vendor drop) that would assist.
If you want customers to start modifying the CLC you should really be making it easy for us to maintain our changes. If Vault had support for vendor drops backed up with a how-to article on Eric's blog that shows how easy it is to use this wonderful new feature from Vault to maintain custom changes to third-party code (using the CLC as an example)... Well, this could very well be the catalyst for some great semi-open source effort from the sourcegear user community.
Thanks
Christian
Ok, so the source code is available - I add the source code to say the following folder $/ThirdpartyCode/Sourcegear/CLC. Branch this so as to keep my changes separate from your changes to give:
$/ThirdpartyCode/Sourcegear/CLC
$/ThirdpartyCode/Sourcegear/Branches/CLC
Assuming the next version you release does not include this additional functionality I then need to merge our code changes with this latest version.
Now this merge may or may or not go smoothly - it depends on whether there decent support in Vault for a Vendor drop (cvs feature) in maybe the form of a wizard (see http://support.sourcegear.com/viewtopic ... endor+drop)
I know you guys will be busy (who's not) but supporting customisations to third party source code is a real pain in the arse particularly when it looks unlikely that Vault is going to get functionality (Vendor drop) that would assist.
If you want customers to start modifying the CLC you should really be making it easy for us to maintain our changes. If Vault had support for vendor drops backed up with a how-to article on Eric's blog that shows how easy it is to use this wonderful new feature from Vault to maintain custom changes to third-party code (using the CLC as an example)... Well, this could very well be the catalyst for some great semi-open source effort from the sourcegear user community.
Thanks
Christian
If you store the CLC version that we provide, then branch it and start modifying it, it should be fairly straightforward to merge later changes with the Merge Branches command.
On the other hand, for this case, since it is something that is not specific to your site, we would be likely to include any changes you send us into the main CLC source for the next major release.
So, either way you should be covered.
Thanks,
On the other hand, for this case, since it is something that is not specific to your site, we would be likely to include any changes you send us into the main CLC source for the next major release.
So, either way you should be covered.
Thanks,