Branch folder creates strange subfolders? In Vault 2.0.4
Moderator: SourceGear
Branch folder creates strange subfolders? In Vault 2.0.4
Dont know if previous versions did it or not as I have only just used this feature.
We store our data in Vault like this ;
Root
Product
Version
(i.e.)
$CompanyA
\\\\$CoolSoft
\\\\\\\\\$1.0
\\\\\\\\\\$1.1
\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\$Forms
$CompanyB
\\\\$OtherSoft
\\\\\\\\\\\$0.9 etc etc
When we roll out a new version we like to create a new folder with the next releases intended version number on level 4 of the tree for everyone to work on - it seemes to me that Branch might be the easiest way to achieve that?
So I tried it, I clicked the $CoolSoft 1.1 and asked it to create a branch called 1.2 I ended up with something like this...
$CompanyA
\\\\$CoolSoft
\\\\\\\\\$1.0
\\\\\\\\\$1.1
\\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\\$Forms
\\\\\\\\\$1.2
\\\\\\\\\\\\\\\$CoolSoft
\\\\\\\\\\\\\\\$Project
\\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\\$Forms
$CompanyB
\\\\\\\\\\\\\\\$OtherSoft
\\\\\\\\\$0.9 etc etc
Quite where these extra folders came from I have no idea? But despite the fact that none of my developers had these folders on their drives these folders contained copies of the files in their parent and showed them as being checked out?
I had to get my team to create pretend folders that matched the same names, fill them with files and check them in just so I could delete the new folders?
Any help with this weird issue appreciated
We store our data in Vault like this ;
Root
Product
Version
(i.e.)
$CompanyA
\\\\$CoolSoft
\\\\\\\\\$1.0
\\\\\\\\\\$1.1
\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\$Forms
$CompanyB
\\\\$OtherSoft
\\\\\\\\\\\$0.9 etc etc
When we roll out a new version we like to create a new folder with the next releases intended version number on level 4 of the tree for everyone to work on - it seemes to me that Branch might be the easiest way to achieve that?
So I tried it, I clicked the $CoolSoft 1.1 and asked it to create a branch called 1.2 I ended up with something like this...
$CompanyA
\\\\$CoolSoft
\\\\\\\\\$1.0
\\\\\\\\\$1.1
\\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\\$Forms
\\\\\\\\\$1.2
\\\\\\\\\\\\\\\$CoolSoft
\\\\\\\\\\\\\\\$Project
\\\\\\\\\\\\\\\$Classes
\\\\\\\\\\\\\\\$Gfx
\\\\\\\\\\\\\\\$Forms
$CompanyB
\\\\\\\\\\\\\\\$OtherSoft
\\\\\\\\\$0.9 etc etc
Quite where these extra folders came from I have no idea? But despite the fact that none of my developers had these folders on their drives these folders contained copies of the files in their parent and showed them as being checked out?
I had to get my team to create pretend folders that matched the same names, fill them with files and check them in just so I could delete the new folders?
Any help with this weird issue appreciated
Last edited by bpd on Mon Aug 02, 2004 10:08 am, edited 1 time in total.
Forum text editor shocker
The forum text parser has destroyed all my nice formatting. sorry it was nicely laid out with indents
Just so I know exactly what you're asking:
You had a folder at the path $/Coolsoft/1.1. You right-clicked the 1.1 folder and chose branch. You typed 1.2.1 as the name of the branch, and chose to put the branch in $/Coolsoft. After the branch, two new folders appeared in $/Coolsoft/1.2.1. Those new folders are Coolsoft and Projects. Is this correct?
You had a folder at the path $/Coolsoft/1.1. You right-clicked the 1.1 folder and chose branch. You typed 1.2.1 as the name of the branch, and chose to put the branch in $/Coolsoft. After the branch, two new folders appeared in $/Coolsoft/1.2.1. Those new folders are Coolsoft and Projects. Is this correct?
Couldnt reproduce it that time
I just gave it a try (as we have just released another major version)
Seemed to work ok this time, despite the fact that one developer had a file checked out, which is what caused it to have a problem part way through the last time.
The last time it started the branch process and stopped with a message stating that files were checked out so it could not continue, I believe it was then that problem had occured - but I may be wrong (busy day)
Seemed to work ok this time, despite the fact that one developer had a file checked out, which is what caused it to have a problem part way through the last time.
The last time it started the branch process and stopped with a message stating that files were checked out so it could not continue, I believe it was then that problem had occured - but I may be wrong (busy day)
You should be able to branch a folder when files underneath it are checked out. Some commands won't allow you to continue if there are files checked out (pin, rename, delete), but branch should work fine.
You mentioned the folder merge command. If you invoked Merge Branches instead of Branch, then I believe it would warn you about checked out files somewhere along the way, and also if you chose a folder one level higher than your branch point, it would create the parent folders in the destination folder (because it is trying to bring changes from the origin folder to the destination folder, which would include the extra folders). Is it possible that is what happened?
You mentioned the folder merge command. If you invoked Merge Branches instead of Branch, then I believe it would warn you about checked out files somewhere along the way, and also if you chose a folder one level higher than your branch point, it would create the parent folders in the destination folder (because it is trying to bring changes from the origin folder to the destination folder, which would include the extra folders). Is it possible that is what happened?
Possible
Sadly not really as I was only using the right click menu, which doesnt have a Merge Branches option on it?
Im starting to suspect the folders have been created by developers (well actually by VB) when they bind to the new source code folder which is now created, when first SC binding VB always asks where in sourcesafe to add files etc and defaults to creating a subfolder which is the name of the project, which is at least one of the folders that appeared for me (the name of the VBP).
Im starting to suspect the folders have been created by developers (well actually by VB) when they bind to the new source code folder which is now created, when first SC binding VB always asks where in sourcesafe to add files etc and defaults to creating a subfolder which is the name of the project, which is at least one of the folders that appeared for me (the name of the VBP).
Best practices
Before I go...
Is using the Branch folder tool in this way a good practice? i.e using it to denote major release's to kick off a new source code subfolder as illustrated in my first post.
I never have any intentions of merging them back together so Im not sure Im using Vault correctly, it just seemed like a nice way to achieve the effect I was after (new sub folder with new version number, history retained)
Whats the best practice if this is wrong? Cheers
Is using the Branch folder tool in this way a good practice? i.e using it to denote major release's to kick off a new source code subfolder as illustrated in my first post.
I never have any intentions of merging them back together so Im not sure Im using Vault correctly, it just seemed like a nice way to achieve the effect I was after (new sub folder with new version number, history retained)
Whats the best practice if this is wrong? Cheers
Re: Best practices
Yes, that's a great use for Branch. We do the same thing here. We do use Merge Branches to merge minor release changes back into the main source trunk, but you don't have to use Merge Branches to make use of Branch.bpd wrote: Is using the Branch folder tool in this way a good practice? i.e using it to denote major release's to kick off a new source code subfolder as illustrated in my first post.